Atualizado a 15 de junho de 2022

VMware SD-WAN™ Orchestrator versão R430-20211221-GA
VMware SD-WAN™ Gateway versão R430-20211020-GA-VCG
VMware SD-WAN™ Edge versão R430-20211007-GA-61583-69704-59629-72423

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

O que está nas notas de versão

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

Utilização recomendada

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

Compatibilidade

A versão 4.3.0 dos Orchestrators, Gateways e Edges Hub suporta todas as versões anteriores do VMware SD-WAN Edge igual ou superior à versão 3.2.0 
Nota: 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.0

4.2.0

4.2.0

4.2.0

4.3.0

4.3.0

4.2.0

4.2.0

4.3.0

4.3.0

4.3.0

4.2.0

4.3.0

4.3.0

4.2.0

4.3.0

4.3.0

4.0.1

4.0.1

4.0.1

4.3.0

4.3.0

4.0.1

4.0.1

4.3.0

4.3.0

4.3.0

4.0.1

4.3.0

4.3.0

4.0.1

4.3.0

4.3.0

3.4.2

3.4.4

3.4.4

4.3.0

4.3.0

3.4.4

3.4.4

4.3.0

4.3.0

4.3.0

3.4.4

4.3.0

4.3.0

3.4.4

4.3.0

4.3.0

3.4.2

3.4.2

3.4.2

4.3.0

4.3.0

3.4.2

3.4.2

4.3.0

4.3.0

4.3.0

3.4.2

4.3.0

4.3.0

3.4.2

4.3.0

4.3.0

  3.3.2 P2 *

  3.3.2 P2 *

  3.3.2 P2 *

4.3.0

4.3.0

  3.3.2 P2 *

 3.3.2 P2 *

4.3.0

4.3.0

4.3.0

 3.3.2 P2 *

4.3.0

4.3.0

  3.3.2 P2 *

4.3.0

4.3.0

  3.2.2 *

  3.2.2 *

  3.2.2 *

4.3.0

4.3.0

  3.2.2 *

  3.2.2 *

4.3.0

4.3.0

4.3.0

  3.2.2 *

4.3.0

4.3.0

   3.2.2 *

4.3.0

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

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

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

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

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

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

Notas importantes

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

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

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, 4.0.2 ou 4.2.1, o Edge seria atualizado conforme esperado. Para obter mais informações, consulte Problema 53676 resolvido.

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

Novas funcionalidades

Automatização da WAN Virtual do Azure no Edge

Um cliente pode ativar um Destino Não-SD-WAN (NSD) via Edge para um Azure vWAN Hub com conetividade IPsec.

Nota: Apenas os caminhos estáticos são suportados ao automatizar a conetividade de um Edge para uma vWAN do Azure.

Azure Private MEC (Multi-Access Edge Compute)

O suporte do SD-WAN Edge no Azure Private MEC permitirá aos clientes ativar o acesso de baixa latência aos serviços de computação e armazenamento implementados no local e implementar CNFs, VNFs e aplicações de terceiros.

BGP sobre IPsec no Edge e Gateway

O BGP sobre IPsec permite que os utilizadores ativem o BGP em túneis de Destino Não-SD-WAN, aumentando o caminho estático oferecido atualmente com a capacidade de aprender e anunciar caminhos dinamicamente com os pontos finais do IPsec de terceiros.

Nota: A funcionalidade não é compatível com a automatização da WAN Virtual do Azure a 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.

IPv6 WAN

O VMware SD-WAN suporta agora o modo de pilha dupla (IPv4/IPv6) ou apenas IPv6 no lado de transporte WAN. IPv6 WAN aborda casos de utilização, como tráfego de utilizador de IPv4 de transporte sobre IPv6 WAN, IPv4 sobre Mix IPv4/transporte de IPv6 e IPv4 sobre Transporte de pilha dupla.

Interface de retorno de vários segmentos

Esta funcionalidade introduz interfaces de retorno, que são interfaces lógicas que estão sempre ativas e acessíveis. É possível utilizar um endereço IP da interface de retorno como endereço IP de origem para vários serviços, como Tráfego de gestão do Orchestrator, Autenticação, DNS, NetFlow, Syslog, TACACS, BGP e NTP. Como as interfaces de retorno estão sempre ativadas e acessíveis, estes serviços poderão receber os pacotes de resposta se, pelo menos, uma interface física configurada para o Edge tiver a acessibilidade de camada 3. Também é possível utilizar as interfaces de retorno como interface de origem para BGP, dado que garante que, quando há instabilidade da interface BGP, não existirá instabilidade na adesão ao BGP se existir, pelo menos, uma ligação de camada 3 disponível.

Orchestrator Bastião

Para clientes com requisitos estritos de segurança (por exemplo, sectores financeiros e governamentais), as suas políticas de segurança ditam que um Orchestrator de produção não pode ser exposto à Internet. O Orchestrator Bastião do VMware SD-WAN é um Orchestrator “sacrificial” que, se comprometido, não resultará em nenhuma perda de informação confidencial do cliente nem cria vulnerabilidades no sistema SD-WAN. O Orchestrator Bastião permite que um cliente efetue um “pré-estágio” de configurações de dispositivo antes de inscrever o dispositivo em serviços de produtos.

Autoridade de Certificado Externa

Grandes empresas e clientes governamentais que planeiam implementar um Orchestrator no local estipularam que o VMware SD-WAN deve utilizar a autoridade de certificado (CA) externa do cliente em vez da autoridade de certificado do Orchestrator autoatribuída por predefinição. A funcionalidade CA externa permite ao Orchestrator descarregar a emissão de certificado para SD-WAN Edges e Gateways para a autoridade de certificado externa de um cliente.

Suporte do modo FIPS para o Orchestrator e Gateway

Um cliente pode agora ativar um Orchestrator e Gateways com Cloud-Init para o modo Federal Information Processing Standard (FIPS).  O modo FIPS desativa os conjuntos de cifras não aprovadas pelo FIPS. O MD5 está desativado e o SHA-1 é utilizado. O modo FIPS destina-se a ser utilizado apenas com novas instalações, nenhum Orchestrator ou Gateway existente pode ser atualizado para esta funcionalidade.

Assinatura e verificação de imagem

Os clientes querem garantir a integridade e autenticidade do software e firmware em execução em dispositivos VMware SD-WAN. A assinatura de imagem garante aos nossos clientes que o software que instalam é autêntico, inalterado e rastreável. Além disso, durante o processo de atualização do software, o dispositivo verifica se todas as imagens de atualização de software foram assinadas pelo VMware, com base numa raiz de confiança armazenada de forma segura no dispositivo.

VMware SD-WAN na WAN Virtual

Com esta funcionalidade, os clientes podem implementar um VMware SD-WAN Edge utilizando uma aplicação gerida num Hub da WAN Virtual do Azure. Isto permite que os clientes aumentem o respetivo tecido VMware SD-WAN nos Edges em ramos, diretamente para o interior dos hubs da WAN Virtual do Azure e emparelharem a informação de routing personalizável da WAN Virtual do Azure com a otimização da entrega do VMware SD-WAN utilizando a Otimização dinâmica de vários caminhos (DMPO) para aceder facilmente a cargas de trabalho em regiões do Azure enquanto usufrui de uma experiência de utilizador final melhorada.

Suporte para novas plataformas de hardware

Edge 510N, Edge 610N, Edge 620N, Edge 640N e Edge 680N

A VMware planeia introduzir vários modelos de hardware SD-WAN Edge novos que não incluem Wi-Fi integrado. Estes incluem o Edge 510N, 610N, 620N, 640N e 680N. Estes modelos Edge serão suportados nesta versão a partir da compilação R430-20210615-GA do Orchestrator. As configurações Wi-Fi efetuadas nas definições do VMware SD-WAN/SASE Orchestrator não afetarão estes modelos Edge.

Limitações da versão: Na versão 4.3.0, o VMware SD-WAN Orchestrator continuará a apresentar as interfaces WLAN para os dispositivos Edge sem Wi-Fi, mesmo que o Wi-Fi não seja suportado. 

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

Embora os modelos Edge 510N, 610N, 620N, 640N e 680N pareçam idênticos aos seus congéneres com capacidade Wi-Fi, a implementação de um Edge com capacidade Wi-Fi e um Edge sem capacidade 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.

Melhorias de funcionalidades

128 segmentos

O VMware SD-WAN suporta agora até 128 segmentos para acomodar as necessidades das grandes empresas e fornecedores de serviços.

Suporte para ADSL2/2+ e VDSL2 para todos os modelos Edge 6x0

Com a versão 3.4.0, foi adicionado suporte para ADSL e VDSL SFP para o Edge 610 e 610-LTE.  Na versão 4.3.0, este suporte também é adicionado ao restante da linha de modelo Edge 6x0 para incluir o Edge 620, 640 e 680. Tal como com o Edge 610/610-LTE, o módulo SFP suportado é o adaptador Metanoia SFP-V5311-T-R xDSL SFP que funciona de acordo com as especificações VDSL2 e ADSL2/2+.

Além disso, os parâmetros DSL estão agora incluídos no VMware SD-WAN Orchestrator como parte do processo de ativação que permite que um Edge 6x0 seja ativado utilizando apenas uma ligação DSL.  O suporte ADSL2/2+ é melhorado adicionando mais parâmetros para a definição de PVC ao configurar a interface SFP.

Suporte de Rede Acelerada Azure

O VMware SD-WAN vVCE adiciona suporte para SR-IOV baseado em Azure (Hyper-V).

Classe de serviço para ligações públicas sem fios

Um cliente pode agora configurar o mapeamento da classe de serviço nas ligações públicas sem fios.

Melhorias da firewall

A funcionalidade de firewall foi melhorada de duas formas:

  • Atualizações do formato de mensagem syslog para registos de firewall.
  • Capacidade de configurar comentários de auditoria numa Regra de Firewall.

Alta disponibilidade

Os clientes podem agora utilizar Edges Virtuais em implementações de uCPE com Alta Disponibilidade no ESXi. Este é o resultado de duas melhorias:

  • Suporte para um endereço MAC único numa interface de alta disponibilidade. Em vez de gerar um MAC virtual partilhado ou comum quando em HA (alta disponibilidade), esta função utiliza o endereço MAC físico para hardware de Edges e o endereço MAC atribuído para Edges virtuais.
  • Suporte para detetar Perda de Sinal (LoS) numa interface HA (alta disponibilidade), que garante que haverá recuperação automática de HA mesmo que a implementação do ESXi esteja a utilizar um switch virtual.

Localização do Orchestrator

A IU do VMware SD-WAN Orchestrator suporta agora a localização em espanhol, japonês, coreano, chinês tradicional e português. Utilize a definição de idioma do browser para selecionar o idioma do Orchestrator.

Melhorias de funções de parceiro

Esta função de administrador de parceiro é melhorada para fazer o seguinte:

  • Gerar e transferir pacotes de diagnóstico de Gateway de parceiro.
  • Ver eventos de Gateway de parceiro e configurar o modo de autenticação.
  • Configurar as definições do cliente e ver e modificar a conta do cliente.
  • Exportar um inventário consolidado de clientes.

Personalização de função

Melhorias nas funções de administrador do cliente e personalizações acrescentadas. Alguns dos casos de utilização destas novas personalizações incluem:

  • Administrador de segurança: um Administrador Padrão personalizado para apenas ser capaz de modificar as configurações no separador Firewall.
  • Administrador de rede:  um Administrador Padrão personalizado para apenas ser capaz de modificar as configurações encontradas nos separadores Política Empresarial (Business Policy) e Dispositivo (Device).  
  • Só de leitura da empresa: neste caso de utilização, devido a motivos de segurança/privacidade, os clientes pretendem que os seus utilizadores apenas de leitura sejam capazes de visualizar o rollup de origens de SO (IOS, Linux, Windows, etc.) em vez de apresentar endereços IP de origem individual.
  • Para o modelo de Gestão cogerido de Telco/Cliente, existe agora a capacidade para personalizar uma função que pode modificar as definições LAN, mas não as definições WAN.

Melhorias de segurança para a política de palavra-passe

A força da palavra-passe pode ser configurada para o seguinte:

  • Os comprimentos mínimos e máximos de carateres da palavra-passe são configuráveis. O comprimento mínimo da palavra-passe predefinido é de 8 carateres e o comprimento máximo é de 32 carateres.
  • A palavra-passe tem de conter carateres numéricos, minúsculos, maiúsculos e/ou especiais. Os requisitos de carateres numéricos e minúsculos estão ativados por predefinição.
  • A palavra-passe não pode corresponder a uma lista das palavras-passe mais utilizadas.
  • A palavra-passe não pode incluir carateres repetitivos ou sequenciais (por exemplo, “aaaaaa”, “1234abcd”). Esta opção está desativada por predefinição.
  • A palavra-passe não pode conter o ID do utilizador no seu todo ou em parte. Esta opção está desativada por predefinição.
  • A nova palavra-passe tem de ser diferente da palavra-passe antiga em um número configurável de carateres. Esta opção está desativada por predefinição.
  • A expiração da palavra-passe pode ser configurada. Esta opção está desativada por predefinição. Quando ativada, a expiração predefinida é de 30 dias.
  • Não podem ser reutilizadas palavras-passe antigas. O número de palavras-passe antigas que podem ser mantidas é configurável. Esta opção está desativada por predefinição. Quando ativada, a predefinição é que a nova palavra-passe não pode corresponder às últimas 5 palavras-passe.

Nota: estas definições são configuradas no SD-WAN Orchestrator por um utilizador operador em Propriedades do sistema (System Properties) e podem ser configuradas para os operadores nesse Orchestrator e globalmente para todos os clientes nesse Orchestrator.

VMware Horizon

O serviço VMware SD-WAN agora inclui a cobertura completa da aplicação VMware Horizon no mapa de aplicação predefinido, incluindo os protocolos Horizon Blast. Assim, será possível garantir que todas as políticas empresariais corresponderão ao tráfego do VMware Horizon e os diagnósticos de fluxo identificarão corretamente o tráfego do VMware Horizon.

Zero Touch Provisioning (ZTP) – Ativação push

Anteriormente, o ZTP exigia que o pessoal de implementação estivesse fisicamente no local para o Edge, enquanto utilizava uma ligação de ativação retirada do Orchestrator sob a forma de um e-mail para ativar um Edge, um método que tem um fraco desempenho de dimensionamento em implementações de grande dimensão. Com a adição da Ativação Push à nossa funcionalidade ZTP, os clientes podem ativar um Edge ligando-o apenas à energia e à Internet.

Integração Zscaler

Como parte da parceria decorrente da VMware com o Zscaler para melhoria da experiência do cliente, a versão 4.3.0 inclui a integração do Início de Sessão Único (SSO) do Zscaler e o suporte para verificações do estado de funcionamento da camada 7.

Alterações à API do Orchestrator desde a versão 4.2.x

A partir da versão de software 4.3.0 do Orchestrator, a VMware suporta os seguintes conjuntos de cifras TLS em todas as APIs públicas do VMware SD-WAN Orchestrator:

  • TLS_AES_256_GCM_SHA384

  • TLS_AES_128_GCM_SHA256

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES128-GCM-SHA256

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

A referência completa à API do portal do VCO 4.3.0 está disponível através de°code.vmware.com.

Nas notas de versão anteriores, a secção API era utilizada para enumerar uma extensa lista de alterações à API do portal do Orchestrator. Com o aumento do número de alterações entre versões que afetam a API do portal, e com uma introdução contínua de APIs públicas inteiramente novas (por exemplo, API SD-WAN v2), decidimos rever esta abordagem com o intuito de manter esta secção mais concisa.

Começando com a versão 4.3.0 e nas versões posteriores, as Notas de versão vão destacar apenas um subconjunto de alterações que a nossa equipa de Engenharia identificou como um potencial risco de perturbação dos clientes API existentes. Entretanto, a equipa de API continuará a fornecer um registo de alterações abrangente para a API do portal como um artefacto transferível juntamente com a Referência API em code.vmware.com. Esperamos adotar uma prática semelhante para outras APIs.

Os responsáveis pelos clientes API existentes podem observar alterações ao comportamento da API decorrentes das alterações de software que se seguem:

  • Problema 53798: imposição de uma validação de sintaxe de pedido mais rigorosa nas chamadas de API para enterprise/insertOrUpdateEnterpriseGatewayHandoff. Esta validação baseia-se precisamente no mesmo esquema de pedido que surge na nossa documentação de API Swagger.
  • Problema 58407: adição de lógica de validação de pedido incremental que impõe um valor mínimo de 0 para o parâmetro de pedido “limite” (limit) para todos os métodos de API que produzem conjuntos de resultados paginados (por exemplo, event/getOperatorEvents, monitoring/getAggregateEnterpriseEvents, monitoring/getEnterpriseEdgeStatus, etc.).
  • A modificação dos privilégios necessários para invocar métodos da API “CRUD” (criar, ler, atualizar e eliminar) relativos a Grupos de Objetos. Considerando que estes métodos exigiam anteriormente permissões para gerir entidades NETWORK_SERVICE, exigem agora autorizações para gerir recursos OBJECT_GROUP. Os utilizadores com funções padrão do Orchestrator atribuídas não devem observar qualquer alteração no comportamento da API como resultado desta alteração. 

Histórico de revisões do documento

3 de junho de 2021. Primeira edição

7 de junho de 2021. Segunda edição

  • Foi adicionada uma nova compilação de Gateway: R430-20210605-GA como a mais recente compilação de Gateway GA.  Esta compilação adiciona uma correção para o Problema 64633, que também é adicionada a esta edição.

15 de junho de 2021. Terceira edição.

  • Foi adicionada uma nota importante sobre o facto de os túneis dos Destinos Não-SD-WAN com um tipo Zscaler serem alterados de IKEv1 para IKEv2 após a atualização do Orchestrator e dos Gateways para a versão 4.3.0.

16 de junho de 2021. Quarta edição.

  • Foi alterada a nova funcionalidade “Azure Private Edge Zones” para “Azure Private MEC (Multi-Access Edge Compute)” como resultado da mudança de nome do produto da Microsoft, em vigor a partir de 16 de junho de 2021.

30 de junho de 2021. Quinta edição.

  • Nova secção adicionada: Suporte para novas plataformas de hardware. Esta secção adiciona o seguinte texto:
    “A VMware tenciona introduzir novos modelos de hardware SD-WAN Edge que não incluem Wi-Fi integrado. Estes incluem o Edge 510N, Edge 610N, Edge 620N, Edge 640N e Edge 680N. Estes modelos Edge serão suportados nesta versão a partir da compilação R430-20210615-GA do Orchestrator. As configurações Wi-Fi efetuadas nas definições do VMware SD-WAN/SASE Orchestrator não afetarão estes modelos Edge.”
  • Foi adicionada uma nova compilação R430-20210615-GA do Orchestrator à secção Problemas resolvidos.  Esta é também a nova compilação predefinida na parte superior das Notas.
  • Foram adicionados dois novos pedidos resolvidos por esta nova compilação: 62355 e 64716

2 de julho de 2021, sexta edição

  • Foi adicionada uma nova compilação GA R430-20210702-GA-61583 do Edge à secção Problemas resolvidos. Esta compilação do Edge aborda um novo problema resolvido n.º 61583.

8 de julho de 2021, sétima edição

  • Foi adicionado um novo Problema pendente à secção Problemas conhecidos do Edge/Gateway: Problema n.º 65885.

13 de julho de 2021, oitava edição

  • Foi adicionada uma nova compilação GA R430-20210709-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. 
  • Esta compilação do Orchestrator aborda os seguintes problemas resolvidos incluídos na secção R430-20210709-GA: 59434, 65526, 65967, 66678 e 66679.

28 de julho de 2021, nona edição

  • Foi adicionada uma nova compilação GA R430-20210727-GA-65293-67191 do Gateway à secção Problemas resolvidos do Edge/Gateway.
  • Esta compilação do Gateway adiciona os problemas corrigidos 65293 e 67191, que se encontram documentados nesta secção.
  • Foi adicionada uma nova compilação GA R430-20210719-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Esta compilação do Orchestrator adiciona os problemas corrigidos 66203 e 67496, que se encontram documentados nesta secção.

5 de agosto de 2021, décima edição

  • Foi adicionada uma nova compilação GA R430-20210729-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Esta compilação do Orchestrator adiciona os problemas corrigidos 66794 e 68577, que se encontram documentados nesta secção.

17 de agosto de 2021, décima primeira edição

  • Foi adicionada uma nova compilação GA R430-20210810-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Esta compilação do Orchestrator adiciona os problemas corrigidos 65253 e 69046, que se encontram documentados nesta secção.
  • Foi corrigida a formulação das Melhorias de segurança para a política de palavra-passe.

8 de setembro de 2021. Décima segunda edição.

  • Foi adicionada uma nova compilação R430-20210903-GA-68994-65293-71052 do Gateway à secção Problemas resolvidos do Edge/Gateway.
  • Esta compilação do Gateway adiciona os problemas corrigidos 68994 e 71052, que se encontram documentados nesta secção.
  • Foi removido o problema em aberto 49738, uma vez que o mesmo não se encontra na compilação 4.3.0.

16 de setembro de 2021. Décima terceira edição. 

  • Foi adicionada às Notas importantes a seguinte nota: Alteração ao delimitador da configuração de filtro BGPv4 para o AS-PATH precedente.

24 de setembro de 2021. Décima quarta edição.

  • Foi adicionada uma nova compilação R430-20210916-GA-VCG do Gateway à secção Problemas resolvidos do Edge/Gateway.
  • Esta compilação do Gateway adiciona os problemas corrigidos 70416, 70590, 70855, 71052 e 71513, que se encontram documentados nesta secção.

30 de setembro de 2021. Décima quinta edição.

  • Foi adicionado um aviso na tabela de compatibilidade de que as versões 3.2.x e 3.3.x se estão a aproximar do fim do suporte com datas e uma ligação para o artigo da BDC.  Foi também adicionado um * a cada versão 3.2.x e 3.3.x na tabela a apontar para esse aviso.

8 de outubro de 2021. Décima sexta edição.

  • Foi adicionada uma nova compilação R430-20211007-GA-61583-69704-59629-72423 do Edge à secção Problemas resolvidos do Edge/Gateway.
  • Esta compilação do Edge adiciona os problemas corrigidos 59629, 69704 e 72423, que se encontram documentados nessa secção.

23 de outubro de 2021. Décima sétima edição.

  • Foi adicionada uma nova compilação R430-20211020-GA-VCG do Gateway à secção Problemas resolvidos do Edge/Gateway.
  • Esta compilação do Gateway adiciona o problema resolvido 63725, que se encontra documentado nesta secção.
  • Foi removido o Problema em aberto 52104, uma vez que foi resolvido na versão 4.2.x, e o Problema em aberto 52483, uma vez que foi fechado antes desta versão.

19 de novembro de 2021. Décima oitava edição.

  • Foi adicionada uma nova compilação GA R430-20211112-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Esta compilação do Orchestrator não adiciona outros pedidos corrigidos, mas contém alterações de desempenho e resolução de problemas exigidas pela VMware Engineering.

4 de janeiro de 2022. Décima nona edição.

  • Foi adicionada uma nova compilação R430-20211221-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.

2 de março de 2022. Vigésima edição

  • Em Suporte para novas plataformas de hardware, foi adicionada uma nota importante: “Nota: Misturar Edges capazes de Wi-Fi e não capazes de Wi-Fi em alta disponibilidade não é suportado” na secção Edge 510N, Edge 610N, Edge 620N, Edge 640N e Edge 680N.

17 de março de 2022. Vigésima primeira edição

  • Em Novas funcionalidades, foi adicionada uma nota ao BGP através de IPsec no Edge e no Gateway a indicar: "A funcionalidade 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”.
  • 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.

24 de março de 2022, vigésima segunda edição

  • Foi adicionado o Problema 84825 à secção Problemas resolvidos do Edge/Gateway.

7 de junho de 2022, vigésima terceira edição

  • Foi adicionado o Problema resolvido 54493 à secção Problemas resolvidos do Edge/Gateway. Este problema foi omitido por engano da edição original das Notas de lançamento da versão 4.3.0.

Problemas resolvidos

Os problemas resolvidos são agrupados da seguinte forma.

Problemas resolvidos do Gateway

Resolvidos na versão R430-20211020-GA-VCG do Gateway

A versão R430-20211020-GA-VCG do Gateway foi lançada a 21/10/2021 e resolve os problemas críticos abaixo desde a versão R430-20210916-GA-VCG do Gateway.

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

___________________________________________________________________

Resolvidos na versão R430-20211007-GA-61583-69704-59629-72423 do Edge

A versão R430-20211007-GA-61583-69704-59629-72423 do Edge foi lançada a 08/10/2021 e resolve os problemas críticos abaixo desde a versão R430-20210702-GA-61583 do Edge.

  • Problema 59629 resolvido: num local 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.

    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 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 72423 resolvido: o VMware SD-WAN Edge fica offline no VMware SD-WAN Orchestrator e não está acessível se o servidor DNS público do Edge não for o DNS da Google.

    Neste caso, o servidor DNS configurado para um Edge no Orchestrator não é o DNS da Google, mas os pacotes DNS para domínios específicos (como *.nyansa.com e *.velocloud.net) continuarão a ser enviados para o servidor DNS da Google (8.8.8.8/8.8.4.4). (Este é um comportamento esperado.) 

    Quando um pacote DNS é recebido do kernel, só é reencaminhado se o IP de destino for o mesmo que o configurado no Orchestrator. Se o IP de destino não corresponder ao configurado no Orchestrator, o Edge ignora esse pacote. No entanto, o Edge não liberta esse pacote, o que provoca uma fuga da memória intermédia. É a fuga da memória intermédia que, em última análise, faz com que o Edge não responda.

    Sem a correção, como uma solução alternativa, os clientes poderiam garantir que o DNS da Google está configurado como o servidor DNS público para todos os seus Edges.  No caso de um Edge num estado inacessível, o cliente necessita de reiniciar o Edge para o recuperar.

___________________________________________________________________

Resolvidos na versão R430-20210916-GA-VCG do Gateway

A versão R430-20210916-GA-VCG do Gateway foi lançada a 24/09/2021 e resolve os problemas críticos abaixo desde a versão R430-20210903-GA-68994-65293-71052 do Gateway.

  • 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 é provocado pelos 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 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 sucesso um pacote de diagnóstico num Gateway é um utilizador operador iniciar sessão no Gateway e, antes de acionar o pacote de diagnóstico no Orchestrator, eliminar os ficheiros de registo de auditoria que se encontram no diretório /var/log/audit do Gateway.

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

___________________________________________________________________

Resolvido na versão R430-20210903-GA-68994-65293-71052 do Gateway

A versão R430-20210903-GA-68994-65293-71052 do Gateway foi lançada a 04/09/2021 e resolve os problemas críticos abaixo desde a versão R430-20210727-GA-65293-67191 do Gateway.

  • Problema 68994 resolvido: os clientes que implementem um túnel do Destino Não-SD-WAN (NSD) com qualquer 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 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 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.

___________________________________________________________________

Resolvido na versão R430-20210727-GA-65293-67191 do Gateway

A versão R430-20210727-GA-65293-67191 do Edge foi lançada a 28-07-2021 e resolve os problemas críticos desde a versão R430-20210605-GA do Edge.

  • 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 67191 resolvido: para um cliente que utilize um Serviço de Segurança na Cloud (CSS) que também tenha ativado a verificação do estado de funcionado da camada 7 para esse CSS, a verificação do estado de funcionado da L7 pode devolver uma falha errada e, consequentemente, os túneis do CSS serão desmontados.

    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.

___________________________________________________________________

Resolvido na versão R430-20210702-GA-61583 do Edge

A versão R430-20210702-GA-61583 do Edge foi lançada a 02-07-2021 e resolve o problema crítico abaixo desde a versão R430-20210528-GA do Edge.

  • Problema 61583 resolvido: se um cliente ativar a Alta Disponibilidade para um local, o VMware SD-WAN Edge ficará offline, o local 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 local.

    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)

___________________________________________________________________

Resolvidos na versão R430-20210605-GA do Gateway

A versão R430-20210605-GA do Gateway foi lançada a 06/06/2021 e resolve o problema crítico abaixo desde a versão R430-20210528-GA do Gateway.

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

Problemas resolvidos do Edge/Gateway

Resolvido na versão R430-20210528-GA

Os problemas abaixo foram resolvidos desde a versão R420-20201218-GA do Edge e a versão R420-20210208-GA-53243-54800 do Gateway .

  • Problema resolvido 34037: um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane após a falha de um túnel de pares.

    Quando um túnel de pares fica inativo, o processo de limpeza utiliza o fc->vpi e atribui-o a NULL. Parecem existir alguns pacotes no pipeline que ainda tinham uma referência a este fc. Como parte do processamento destes pacotes, o fc->vpi é acedido e é NULL, portanto, o processo de Gateway atinge uma exceção e reinicia.

  • Problema 34626 resolvido: pacotes de controlo inválidos de um VMware Edge para um VMware SD-WAN Gateway podem fazer com que o Gateway sofra uma falha do Serviço dataplane e reinicie.

    Para os fluxos do Edge para o Gateway, o Edge envia uma mensagem de controlo para o Gateway para sincronizar as ações da política empresarial para cada fluxo. Se a mensagem de controlo tiver uma ação inválida, poderá fazer com que o Gateway seja reiniciado quando tenta encaminhar os pacotes de dados do fluxo com um conjunto de ação inválido.

  • Problema resolvido 39232: num VMware SD-WAN Edge com o BGP ou OSPF ativado, o Edge pode encontrar uma falha do Serviço dataplane após um tempo limite excedido enquanto espera que um socket de bloqueio regresse de Tx.

    Isto é normalmente observado com a seguinte assinatura:
    #0 0x00007f5c09f34754 in send () from deps/lib/libpthread.so.0
    #1 0x000000000092cc7a em vc_zeb_send_to_client (buf=0x7f5aa7fed580 "", length=<optimized out>, client=0x7f5ad402ec90) em /mnt/build/workspace/master-nightly-build/common/libs/drp/vc_zebra.c:188

    Os processos de routing e o dataplane do Edge comunicam com um socket TCP no localhost. Dependendo do runtime de alguns threads, é possível que o sistema de fila de tarefas (ksoftirqd) no núcleo local receba um runtime mínimo para entrega de pacotes ao socket aberto para o processo de routing, o que leva a uma chamada Tx bloqueada para o thread BGP e/ou OSPF.

    A prioridade de threads para os threads BGP e OSPF é agora reclassificada para todos os núcleos que beneficiam da utilização do agendador de kernel para antecipar em vez de ceder voluntariamente o núcleo e permite um maior runtime e preferência cooperativa com o ksoftirqd.

    Nota: este mesmo problema também é rastreado no pedido 52127 duplicado que é omitido destas Notas.

  • Problema 39374 resolvido: o teste de largura de banda será ativado tanto nos caminhos do Gateway principal como secundário após alterar a ordem do Gateway de parceiro na IU do VMware SD-WAN Orchestrator e acionar o teste de largura de banda manualmente.

    Inicialmente, quando é realizada uma alteração de configuração do Gateway de parceiro, um teste de largura de banda deveria ser acionado no caminhos do Gateway principal e do Gateway secundário. Quando a ordem dos Gateways de parceiro é alterada e o teste de largura de banda é acionado manualmente, o teste de largura de banda deverá ser acionado nos caminhos do Gateway principal e do Gateway secundário.  Os testes de largura de banda para ambos os caminhos, para todos os Edges atribuídos pode colocar um esforço elevado sobre o Gateway de parceiro e possivelmente provocar uma falha do Serviço dataplane.

  • Problema resolvido 39501: num local que utiliza um par de VMware SD-WAN Edges numa topologia de Alta Disponibilidade, se a Interface HA (por exemplo, GE1 ou LAN1) estiver inativa, os Edges entrarão num estado duplo (split-brain), o que significa que ambos permanecerão Ativos.

    Um local de HA num estado duplo (split-brain) tem graves consequências, dado que o tráfego do cliente não será encaminhado durante 3 a 4 minutos até que o local recupere.

  • Problema 39654 resolvido:  num site que utiliza um par de VMware SD-WAN Edges numa topologia de Alta Disponibilidade, uma transição de Edge de Ativo para Em espera pode encontrar uma falha do Serviço dataplane durante a criação do fluxo.

    Os fluxos apenas são criados no Edge Ativo. No entanto, se ocorrer uma transição do estado de HA de Ativo para Em espera durante o processo de criação de fluxo, o novo Serviço dataplane Edge em espera falhará, uma vez que o software não permite a criação de fluxo quando um Edge está no estado em espera. O impacto sobre o cliente é mínimo, dado que se trata do novo Edge em espera com o problema, mas deverá existir um registo nos Eventos relativamente a este problema.

  • Problema 40124 resolvido: quando um utilizador desativa a interface CELL1 num VMware SD-WAN Edge 510-LTE no VMware SD-WAN Orchestrator, os túneis de interface CELL1 permanecem ativos.

    Quando a CELL1 é desativada no Orchestrator, não é totalmente desativada e os túneis permanecem ativos. A página Monitorizar (Monitor) também apresenta a interface CELL1.

  • Problema 41837 resolvido: o endereço IP NAT de origem e destino é impresso num registo VMware SD-WAN Edge em vez do endereço IP original.

    Os registos de firewall do Edge devem apresentar o endereço IP original de origem e destino, mas em vez disso é impresso o IP NAT, prejudicando gravemente a utilidade dos registos de firewall.

  • Problema 43257 resolvido: os caminhos num VMware SD-WAN Gateway de parceiro estão em falta quando existe uma sequência de alterações realizadas para a atribuição de Gateway de parceiro para um VMware SD-WAN Edge.

    Quando um Gateway de parceiro é removido de uma lista de Gateways atribuídos, um route_event_queue correspondente também é removido. Mas quando o Gateway de parceiro é novamente adicionado, não é criado nenhum route_event_queue para os segmentos correspondentes. À medida que a criação da janela do evento de caminho de Protocolo de routing VeloCloud (VCRP) falha com um erro, outras distribuições de caminhos não são realizadas corretamente e isso resulta em atualizações de caminho em falta no Gateway de parceiro para o Edge.

    Sem esta correção, a única forma de resolver este problema é remover um Gateway de parceiro de todos os segmentos e adicionar o Gateway novamente, o que vai atualizar corretamente as informações de segmento para esse par específico e ajudar na recriação da janela VCRP correspondente.

  • Problema 43278 resolvido: se um utilizador configurar um filtro BGP de saída para corresponder ao prefixo ou caminho predefinido e, em seguida, definir um Caminho AS precedente, o prefixo ou caminho predefinido será anunciado para o BGP vizinho, mas não existirá nenhum Caminho AS precedente.

    Um filtro vizinho BGP de saída definido para corresponder a um prefixo e um Caminho AS precedente definido não funciona em nenhum prefixo originado através da declaração de “Redes” de configuração Avançada BGP. Também não funciona para um caminho predefinido com origem num vizinho através do vizinho “Origem DR” (DR Originate), através da caixa de verificação Anunciar caminho predefinido “condicional” avançado BGP (BGP Advanced “Conditional” Default Route Advertise).

    Além disso, quando utiliza uma configuração de caminho estático no VMware SD-WAN Edge, nenhum caminho predefinido nem caminho estático não DR definido para “Anunciar” (Advertise) será anunciado para um vizinho BGP com o Caminho AS precedente; o único AS no prefixo é o próprio AS do Edge.

  • Problema 44832 resolvido: o tráfego de um Destino Não-SD-WAN (NSD) via Edge para outros Destinos Não-SD-WAN via Edge (isto é, “devolução” (hairpinning) ou “Retorno NAT” (NAT loopback)) é ignorado no VMware SD-WAN Edge.

    O tráfego NSD para NSD através de um VMware SD-WAN Edge não é suportado até à versão 4.3.0. Com a adição da nova funcionalidade de BGP sobre IPsec via Edge, os Edges podem agora suportar trocas de caminho de devolução NSD-NSD juntamente com outro tráfego.

  • Problema 46365 resolvido: num site que utiliza um par de VMware SD-WAN Edges numa topologia de Alta Disponibilidade, se um utilizador estiver a realizar um SNMP walk, poderá observar um resultado de falha numa interface WAN do Edge em espera.

    Se um utilizador tentar utilizar o SNMP walk numa interface WAN que não esteja ligada a um dispositivo ativo, não é devolvida nenhuma resposta, dado que o kernel local não tinha conhecimento da ligação WAN.

  • Problema 47244: num VMware SD-WAN Edge 6x0 ativado com o DPDK ativado e alguns SFPs de Cobre, o Edge mostrará a ligação como “ATIVA” (UP) mesmo quando não está inserido nenhum cabo na IU do VMware SD-WAN Orchestrator.

    Este problema resulta na confusão do utilizador quanto ao estado real de uma determinada porta SFP para um Edge na linha de modelo 6x0.

    Antes desta correção, a única forma de resolver o problema era ligar um cabo aleatório e, em seguida, desligar esse cabo da porta SFP afetada.

  • Problema 47664 resolvido: numa configuração de Hub e Spoke onde Ramo a Ramo através da VPN do Hub está desativado, tentar inverter o sentido do tráfego de ramo-a-ramo com um caminho resumido num switch/router L3 provocará ciclos de routing. 

    Spoke1 <-vcmp-> Hub <-GEx-> Firewall Externa <-GEx-> Edge Hub <-vcmp-> Spoke2

    Nesta topologia, o tráfego do Spoke1 vai para o Hub através do VeloCloud Management Protocol (vcmp), depois para uma firewall externa através de uma porta física regressando depois ao Hub e, em seguida, para o Spoke2 através de VCMP. Note que os pacotes do Spoke1 para o Spoke2 têm de atravessar o Edge Hub duas vezes (primeiro quando vão do Spoke1 para a firewall e depois quando vão da firewall para o Spoke2). Antes da versão 3.4.0, este cenário funcionou corretamente dado que o Edge Hub criaria dois fluxos separados para o manuseamento dos pacotes no Hub (isto é, um fluxo para lidar com pacotes entre o Spoke1 e a firewall externa e outro para lidar com pacotes entre o Spoke2 e a firewall externa.)

    Devido às alterações na forma como os fluxos são criados e os pacotes são classificados para fluxos (introduzidos na versão 3.4.0), apenas um único fluxo é criado no Edge Hub neste cenário. Isto faz com que o tráfego de retorno da firewall externa seja enviado de volta para o Spoke de onde acabou de ser enviado.

    Sem esta correção, a única solução alternativa para este problema é configurar a VPN de Cloud para permitir a VPN ramo a ramo e selecionar “Utilizar Hubs para VPN” (Use Hubs for VPN).

  • Problema 48211 resolvido: num VMware SD-WAN Edge que tem a Firewall ativada, durante o reinício do Serviço dataplane Edge, algumas regras iptable podem não ser instaladas devido ao erro “Recurso indisponível” (Resource unavailable).

    A inserção de regras iptables pode causar o erro “Recurso indisponível” (Resource unavailable) quando chamada sem a opção -w, o que pode resultar numa falha das regras iptable, uma vez que não existe um mecanismo de repetição para a falha.

    Sem a correção, se foram vistos erros de “recurso indisponível” (resource unavailable), a única forma de resolver o problema será tentar instalar a regra iptable novamente com opção -w manualmente.

  • Problema 48958 resolvido: um VMware SD-WAN Gateway pode perder conetividade numa interface ligada.

    Quando o Protocolo de Gestão VeloCloud (VCMP) e a porta WAN estiverem definidos para utilizar a mesma porta, a configuração de handoff da VLAN do gateway de parceiro pode fazer com que o Gateway fique offline devido à falha das resoluções ARP. Com esta correção, quando o VCMP e a porta WAN forem idênticos, a configuração de handoff da VLAN do VMware SD-WAN Orchestrator será rejeitada no Gateway.  Sem esta correção, a solução alternativa é não atribuir a mesma porta a VCMP e a WAN.

  • Problema 50233 resolvido: um VMware SD-WAN Edge que utiliza a versão 3.4.x ou superior não enviará informações para interfaces LAN físicas através do SNMP. 

    Em versões anteriores à 3.4.x quando o VMware SD-WAN utilizou o net-snmp, as interfaces LAN foram enviadas através de SNMP. Na versão 3.4.x, adicionámos o nosso próprio snmpagent, que recolhe os dados do comando debug.py – interfaces e essa saída não tem informação sobre interfaces LAN. A correção adiciona interfaces LAN a esse comando para que o snmpagent possa enviar os dados através do SNMP.

  • Problema 51025 resolvido: quando existe instabilidade na ligação WAN (alterna rapidamente entre um estado ativo e inativo) num VMware SD-WAN Edge, a entrada da tabela de encaminhamento para o gateway predefinido da interface encaminhada pode ser removida e não pode ser reaplicada.

    Quando um Edge encontra este problema, existe uma ligação instável e a entrada de caminho de gateway predefinido é removida para a interface que utiliza essa ligação, o que resulta numa tabela de encaminhamento vazia para a interface. No entanto, se for deixada com uma tabela de encaminhamento vazia, o rastreamento da ligação Linux (conntrack) será encaminhado para a tabela seguinte por predefinição, fazendo com que todos os pacotes saiam através da interface encaminhada errada.

  • Problema 51165 resolvido: a API devolve “500 Erro interno do servidor” (500 Internal Server Error) numa tentativa de criar um VMware SD-WAN Edge com um ID de perfil de empresa inválido.

    Quando um utilizador envia “POST/sdwan/enterprises/{logicalId}/edges/” com carga útil com um ID de perfil específico do Edge como configurationId ou “POST /sdwan/enterprises/{logicalId da segunda empresa}/edges/” com configurationId que pertence à primeira empresa; é devolvido um “500 Erro interno do servidor” (500 Internal Server Error). O resultado esperado neste cenário é que a API responda com a mensagem de erro “422 Entidade não processável” (422 Unprocessable Entity) ou o erro genérico “400 Pedido incorreto” (400 Bad Request), que menciona o ID de configuração de empresa inválido.

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

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

  • Problema 51502 resolvido: os túneis dinâmicos ramo a ramo são aceites pelos VMware SD-WAN Edges que não têm uma VPN ramo a ramo ativada.

    Os Edges respondem sempre a túneis dinâmicos, mesmo quando não têm a VPN ramo a ramo ativada. Os túneis também podem formar-se mesmo que um lado esteja definido como “Para Edges dentro do Perfil” (To Edges within Profile) e o outro lado esteja definido como “Para todos os Edges” (To All Edges).  Existe um impacto no campo, dado que os túneis de entrada não podem ser controlados. Num caso de campo, os Edges do Ramo formam túneis dinâmicos para Edges Hub de outras regiões, o que por sua vez provoca outros problemas de routing no backbone da empresa.

  • Problema 51837 resolvido: se um utilizador configurar um valor de número/número inteiro para algumas opções DHCP, o dnsmasq falhará para o VMware SD-WAN Edge.

    Este problema é específico da Opção 43 do DHCP e é adicionada uma validação para garantir que os valores numéricos funcionem ao configurar para estas opções.

  • Problema 52710 resolvido: o estado de Alta Disponibilidade apresentado no VMware SD-WAN Orchestrator por vezes não é exato.

    Um estado que indica que o VMware SD-WAN Edge não faz o push para o Orchestrator é “Falhou” (Failed). Em certos cenários, como o Edge em espera ficar inativo ou o Edge ativo não conseguir comunicar com o Edge em espera, o estado de HA não é corretamente apresentado no Orchestrator. Tal deve-se ao envio de dados incorretos do Edge para o Orchestrator dado que “Falhou” (Failed) não é um estado disponível.

  • Problema 52991 resolvido: um par de VMware SD-WAN Edges configurados para Alta Disponibilidade que também têm VNFs implementados vão emitir um estado de HA incorreto quando um VNF está desligado.

    Após um VNF ser desligado, o estado do VNF HA deve apresentar 0, uma vez que o VNF não está ativo. O estado do VNF HA não será monitorizado se o VNF estiver desligado, como tal, o Orchestrator apresentará o último estado quando o VNF estava ligado.

  • Problema 53159 resolvido: para um site implementado numa topologia de Alta Disponibilidade que também utiliza VNFs, o endereço IP atribuído a um VNF Em espera pode ser atribuído pelo servidor DHCP no VMware SD-WAN Edge a uma LAN ligada do lado do cliente, caso o intervalo de IP do servidor DHCP coincida com o VNF em espera.

    O endereço IP do VNF em espera não é adicionado nos endereços IP reservados/já utilizados. Como resultado, é possível que o servidor DHCP possa indicar o endereço IP do VNF em espera a um dispositivo de cliente.

  • Problema 53518 resolvido: a execução do snmpwalk localmente num VMware SD-WAN Gateway não funciona corretamente.

    Ao executar um snmpwalk num Gateway, são observados os seguintes problemas:

    1. Índice de caminho errado encontrado. Deve consistir em {vcgVceUUID, vcgPathIfIntId, vcgPathGwAddrType, vcgPathGwAddr }
    2. Contador de caminhos inconsistente. A expectativa é que o contador de caminhos represente todos os caminhos ATIVOS (ALIVE) encontrados em debug.py --v --path.
    3. Contador ARP inconsistente. O snmpagent do Gateway comunica o contador, incluindo a entrada ARP ATIVA (ALIVE) e INATIVA (DEAD) apenas com os detalhes ATIVOS (ALIVE). A expectativa é que este deve comunicar apenas as entradas ATIVAS (ALIVE) ou todas.
    4. Atualiza o snmpd.conf para permitir todos os outros acessos de IP por predefinição.
  • Problema 53415 resolvido: numa empresa do cliente onde o Edge Network Intelligence (ENI) está ativado, se o VMware SD-WAN Edge da empresa tiver o Wi-Fi ativado, a página ENI poderá apresentar um endereço MAC incorreto para o ponto de acesso de Wi-Fi e o ponto de acesso IP apresentará 160.254.3.1.

    O problema é o resultado de uma configuração errada do endereço MAC do ponto de acesso à Wi-Fi que está a ser definido para um valor chamado “selfMacAddress’” e o endereço IP do ponto de acesso está sempre configurado para 160.254.3.1 na página ENI. A correção derivará o endereço MAC da interface de Wi-Fi wlan0 e o endereço IP da interface de análise.

  • Problema 53551 resolvido: ao ativar um VMware SD-WAN Gateway com a ferramenta de linha de comando activate.py, é emitida uma mensagem “Nenhum módulo com o nome zmq” (No module named zmq) enquanto a ativação prossegue normalmente.

    Esta mensagem incorreta é apresentada em todas as ativações de Gateway. No entanto, não afeta de forma alguma o processo de ativação (isto é, é puramente estética).

  • Problema 53651 resolvido: num local de cliente que utiliza uma topologia de Alta Disponibilidade melhorada, ao fazer uma alteração de configuração para uma definição do dispositivo VMware SD-WAN Edge que exige um reinício do serviço Edge, podem ocorrer duas falhas de recuperação automática da HA em sucessão.

    Para uma alteração da configuração da definição do dispositivo que exige um reinício do serviço Edge, o módulo de HA atualiza erradamente a contagem de LAN/WAN para o VMware SD-WAN Gateway antes de o serviço Edge ser reiniciado durante o processamento da configuração. Como resultado, quando a recuperação automática da HA inicial ocorre e o serviço do Edge ativo atual reinicia como parte da despromoção para Em espera, o Gateway não compreende que o novo Edge em espera tem uma melhor contagem de LAN/WAN e envia um comando de recuperação automática para o recém-promovido Edge ativo, levando a uma segunda recuperação automática.

    Nota: para uma lista das alterações à configuração do Edge que podem desencadear um reinício do serviço, consulte o artigo BDC, Alterações à configuração do VMware SD-WAN Edge que podem desencadear um reinício do serviço (60247)

  • Problema 53676 resolvido: na plataforma VMware SD-WAN Edge 3x00, períodos muito breves de instabilidade da tensão de entrada, mesmo de apenas 4 milissegundos, podem fazer com que o Edge reinicie.

    Este problema é normalmente visto quando se utiliza uma Fonte de Alimentação Ininterrupta (UPS) que sofre de ligeiras instabilidades da tensão de saída ao mudar da rede elétrica para a bateria. A correção para este problema atualiza o firmware do Edge para que tolere 20 a 30 ms de instabilidade da tensão antes do reinício do Edge.

    Nota: a atualização do firmware 3x00 prolongará o tempo de atualização do Edge para 3 a 5 minutos caso o Edge não tenha atualizado anteriormente o firmware ao utilizar a versão 3.4.5 ou 4.0.2.

    Para um modelo Edge 3x00 sem esta correção, a única opção para o cliente é utilizar uma UPS mais sofisticada que possa mudar a sua entrada de tensão sem qualquer instabilidade na tensão de saída. 

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

    Se um VMware SD-WAN Edge detetar perdas de tráfego recebido do Gateway, enviará uma mensagem de confirmação negativa (NACK) para o Gateway para transmitir novamente os pacotes perdidos. O Gateway verifica os blocos de retransmissão para retransmitir os pacotes. Idealmente, o Gateway deve parar a retransmissão quando todos os blocos forem verificados, mas o Gateway verifica repetidamente os blocos de retransmissão até atingir o número de sequência na mensagem NACK e isto pode fazer com que o thread monitorizado no Gateway detete isto como um thread suspenso e reinicie o gateway.

  • Problema 53789 resolvido: nos Edges Virtuais do VMware SD-WAN em execução no ESXi, /var/log/messages é preenchido com uma mensagem de erro indevida a cada 30 segundos.

    A mensagem de erro indevida será apresentada como GuestInfoGetDiskDevice: Nome do dispositivo de disco em falta; Mapeamento VMDK indisponível para “/”, fsName: “dev/root” e é sempre iniciado em /var/log/messages, preenchendo /var/log/messages e o seu homologo /velocloud/log/messages* guardado, fazendo com que as mensagens mais importantes sejam alternadas e perdidas ao consultar os registos do Edge afetado.

  • Problema 53828 resolvido: o tráfego Cloud via Gateway muda para tráfego Direto para Cloud (Direct to Cloud) após a recuperação automática de Alta Disponibilidade.

    Após uma recuperação automática de HA, se o caminho para o VMware SD-WAN Gateway não estiver ativo quando o tráfego alcançar o VMware SD-WAN Edge, o tráfego passará a “Direto para cloud” (Direct to Cloud) em vez de “Cloud via Gateway”.  Esta é uma situação prejudicial para o tráfego confidencial do cliente, uma vez que o tráfego Direto para Cloud (Direct to Cloud) não utiliza a Otimização dinâmica de vários caminhos (Dynamic Multi-Path Optimization) nem as melhorias para participante disponíveis com o DMPO.

  • Problema 53929 resolvido: num local de cliente que utiliza uma topologia de Alta Disponibilidade melhorada, após uma recuperação automática de HA, o fluxo “Cloud via Gateway” muda para caminho “Direto para Cloud” (Direct to Cloud).

    Após uma recuperação automática de HA, se o caminho para o VMware SD-WAN Gateway não estiver ativo quando o tráfego alcançar o VMware SD-WAN Edge, o tráfego passará a “Direto para cloud” (Direct to Cloud) em vez de “Cloud via Gateway”. Esta situação pode ter um impacto significativo nos fluxos que dependem das otimização dinâmica de vários caminhos como o tráfego em tempo real (por exemplo, voz e vídeo) dado que o tráfego direto não utiliza estas otimizações.

  • Problema resolvido 54136: num local que utiliza uma topologia de Alta Disponibilidade, um VMware SD-WAN Active Edge pode iniciar um reinício do Serviço dataplane, resultando numa recuperação automática de HA.

    O Edge ativo consome uma elevada quantidade de memória quando existe um número elevado de fluxos (1,9 milhões de fluxos por segundo).  Quando o consumo de memória atinge um nível crítico, o Edge será reiniciado para limpar a memória e provocar uma recuperação automática.

  • Problema 54493 resolvido: um operador ou um administrador de parceiro pode observar um aumento do número de handoff queue drops para o tráfego do Edge num VMware SD-WAN Gateway. 

    Relativamente a este problema, o Gateway não teria problemas de utilização da CPU nem eliminações de DPDK, O problema é desencadeado por um evento do plano de controlo (por exemplo, recálculo de caminho) e o Gateway começa a eliminar os pacotes do Edge durante o handoff a diferentes threads no pipeline do Gateway. O motivo do problema é um tamanho de fila que não é suficientemente grande para armazenar os pacotes.

  • Problema resolvido 54694: quando um cliente utiliza as consultas SNMP, a monitorização do SNMP proporciona medições imprecisas para o tráfego de saída

    A chamada SNMP para IF-MIB::ifHCOutOctets entrega pacotes TX em vez de Bytes TX, o que resulta em contagens de octetos de saída imprecisas que afetam a capacidade do cliente de monitorizar a empresa. Este problema é o resultado de o processo snmpagent monitorizar pacotes Tx versus bytes Tx.

  • Problema 55182 resolvido: os caminhos de Destino Não-SD-WAN são alterados sem o caminho de atualização estar selecionado.

    Quando a ordem de configuração global do OFC (Controlo de fluxo de overlay) ou as sinalizações NSD-global-advertise são alteradas, as alterações que afetam os caminhos NSD serão aplicadas mesmo que a opção de atualizar caminhos não esteja ativada. Isto foi provocado pela instabilidade no túnel IPsec.

  • Problema 55349 resolvido: um site que implementa VNFs numa topologia de Alta Disponibilidade encontrará uma recuperação automática de HA e a imagem VNF não será descarregada se o local tiver previamente implementado VNFs em HA e depois o utilizador tiver desativado a HA enquanto os VNFs estavam ativos.

    Quando o VNF HA é implementado num par HA de VMware SD-WAN Edges, após cancelar a implementação de um VNF HA anteriormente implementado e ativo nos mesmos Edges, quando a implementação está a decorrer (isto é, na fase de transferência da imagem), ocorre uma recuperação automática da HA devido a um Edge em espera assumir que o VNF está ativo no mesmo. Esta súbita recuperação automática faz com que o Edge Ativo pare de tentar transferir a imagem VNF e o VNF não seja implementado em ambos os Edges. Sem a correção, um utilizador deve reiniciar os Edges de HA.

  • Problema 55827 resolvido: a sessão BGP em que a relação de vizinho de BGP inclui a autorização MD5 pode não ser estabelecida.

    Uma palavra-passe MD5 BGP configurada com caracteres especiais (por exemplo, $, em que a palavra-passe é $123) tem problemas e não forma uma sessão BGP com o par.  Sem a correção, a ação recomendada consiste em configurar a palavra-passe MD5 BGP com texto simples.

  • Problema 55949 resolvido: em certos cenários, um túnel do Destino Não-SD-WAN (NSD) via Gateway fica inativo e não recupera por um determinado período de tempo.

    Numa situação em que o VMware SD-WAN Gateway aciona uma recodificação IKE (Internet Key Exchange) com qualquer outro destino NSD e a tentativa de recodificação não é bem-sucedida devido a um problema de rede no meio da negociação, a recodificação IKE continuará a tentar. Quando uma ligação é novamente estabelecida, é possível que o evento de deteção de pares inativos (DPD) elimine uma Associação de Segurança (SA) de Fase1 recém-criada. Isto faz com que a SA IPsec seja eliminada, assim como alguns pares, nomeadamente com o Zscaler. Quando um par eliminar a SA IPsec, o Gateway não será capaz de detetá-la e o túnel ficará inativo até ao momento da próxima recodificação.  Sem a correção, a única forma de forçar esta recodificação é devolver o túnel através da desativação e reativação do NSD afetado através do VMware SD-WAN Orchestrator.

  • Problema 56149 resolvido: após o Cálculo Dinâmico de Custo (DCC) ser ativado numa empresa de cliente que está a utilizar o BGP, um VMware SD-WAN Edge pode apresentar um valor de preferência de caminho incorreto para caminhos corrigidos automaticamente se o caminho BGP para o caminho de underlay ficar instável.

    O impacto para o cliente é o routing assimétrico devido à preferência do caminho remoto incorreto, o que resulta numa latência maior e fraco desempenho em todas as aplicações do cliente. Após a ativação do DCC, o novo valor de preferência da base de informações de routing (RIB) deve ser atualizado no caminho e o caminho deve ser novamente anunciado para o VMware SD-WAN Gateway com o novo valor de preferência RIB, que é, em seguida, comunicado a todos os Edges. A origem do problema é que quando o caminho é corrigido automaticamente, esta preferência RIB não é atualizada na tabela FIB do par Edge, o que mantém o valor antigo anterior ao DCC. 

  • Problema 56346 resolvido: um cliente pode observar Handoff Queue Drops quando estiver a olhar para uma página Monitor > Sistema (Monitor > System) do VMware SD-WAN Edge.

    As atualizações de evento de caminho VCRP (VeloCloud Route Protocol) levam a Handoff Queue Drops no thread de dados do VCMP (VeloCloud Management Plane).  Isto ocorre quando uma atualização de caminho é recebida, todos os caminhos do respetivo segmento são invalidados. E leva a novas pesquisas de caminho no caminho dos dados. Uma função particular que é chamada como parte da pesquisa de caminho faz uma operação de enumeração de hash dispendiosa levando a um aumento de 40% na utilização de thread de dados VCMP.  Para a instância onde este problema foi encontrado no campo, a quantidade de Handoff Queue Drops não foi suficiente para ter impacto no desempenho de rede.

  • Problema 56483 resolvido: os valores de latência, instabilidade e perda de pacotes não aparece na monitorização em direto da ligação WAN num VMware SD-WAN Orchestrator no ecrã Monitorizar > Transportar (Monitor > Transport).

    Os utilizadores não conseguem obter dados em tempo real relativos à latência, instabilidade ou perda de pacotes para uma ligação WAN em particular em Monitorizar > Transportar (Monitor > Transport), com o gráfico apresentado como uma linha horizontal. Além disso, ao olhar para o ecrã Monitorizar > Edge > Visão geral (Monitor > Edge > Overview), todos os valores de perda, instabilidade e latência são expressos como “0”. As estatísticas históricas serão apresentadas corretamente em Monitorizar > Transportar (Monitor > Transport). Este problema apenas afeta as estatísticas do “Modo em tempo real”. 

  • Problema 56645 resolvido: existem instabilidades frequentes na ligação WAN quando um VMware SD-WAN Edge 610 está ligado a certos Pontos de Acesso Meraki.

    Quando um Edge 610 está ligado a um ponto de acesso Meraki M36 (ou modelos semelhantes), a ligação de Ethernet encontra frequentemente ligações ignoradas. Este é o resultado de um problema de controlador no Edge 610.

  • Problema 56876 resolvido: os VMware SD-WAN Edges a executar ramo a ramo dinâmico podem esgotar a memória disponível e desencadear um pânico do kernel, mesmo não havendo fugas da memória do Edge.

    Quando os túneis dinâmicos são criados, uma pequena quantidade de memória é reservada para armazenar contadores por pares. Quando o túnel dinâmico é desmontado, esta memória não é limpa para otimizar o tempo de ativação da próxima vez que este mesmo par se ligar. Num Edge pequeno (por exemplo, Edge 500, 510, 520, 610) que se liga a muitos destinos diferentes ao longo do tempo, isto pode eventualmente esgotar a memória disponível e acionar um pânico do kernel e um reinício do Edge.  Sem esta correção, o utilizador deverá reiniciar proativamente o serviço Edge se a utilização da memória for superior a 90% das estatísticas de estado de funcionamento quando estas são observadas no ecrã do Edge em Monitorizar > Sistema (Monitor > System) no VMware SD-WAN Orchestrator.

  • Problema 56931 resolvido: um local de cliente que configurou um Destino Não-SD-WAN (NSD) via Edge pode apresentar Estatísticas de Estado de Funcionamento do Edge incorretas na IU do VMware SD-WAN Orchestrator.

    Quando um NSD é configurado no Edge, o serviço SD-WAN envia as estatísticas de estado de funcionamento do Edge para o Orchestrator com uma hora de início de 0 pela primeira vez após o reinício. Isto faz com que o Orchestrator apresente dados errados após o reinício do Edge.

  • Problema 57011 resolvido: para um local configurado com uma topologia de Alta Disponibilidade, sempre que os segmentos são adicionados e, em seguida, eliminados nesse local, 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 local também sofrerá uma recuperação automática da HA.

    Quando os segmentos são adicionados e, em seguida, eliminados de um local de HA, existe o potencial para segmentos obsoletos (isto é, 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 de 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 57169 resolvido: o utilizador observará a presença de caminhos BGP extraviados mesmo quando o par BGP multi-hop estiver inacessível.

    Para segmentos não globais, a mensagem de atualização de rastreamento de próximo hop (NHT) não é processada pelo processo BGP quando a acessibilidade diminui. Como resultado, quando um par BGP multi-hop se tornar inacessível, os caminhos aprendidos pelo BGP podem não ser eliminados imediatamente. Só serão eliminados quando o Hold Timer BGP expirar e a vizinhança ficar inativa.

  • Problema 57644 resolvido: a sessão BFD não está inativa quando a acessibilidade do próximo hop estiver inativa.

    A sessão BFD num segmento não global não fica inativa quando um caminho estático para aceder ao endereço IP do par BFD é eliminado, o que significa que não existe nenhum caminho disponível para aceder ao endereço IP do par.

  • Problema 58061 resolvido: a informação de uma interface PPPoE não pode ser recolhida através do SNMP.

    O SNMP walk IFMIB não apresenta informações relativas às interfaces WAN que têm o PPPoE configurado.

  • Problema 58075 resolvido: num VMware SD-WAN Edge onde foi ativada a Alta Disponibilidade, um SNMP walk/consulta excederá o limite de tempo.

    A saída de consulta SNMP devolverá apenas resultados parciais e, em última análise, resultará num tempo limite excedido num Edge com a HA ativada.

  • Problema 58535 resolvido: quando um cliente tiver configurado uma firewall com estado e, em Proteção de Rede e Flood (Network & Flood Protection ), também tiver configurado uma lista de negações, a lista de negações é definida automaticamente com as definições mais agressivas para as novas ligações e a firewall com estado bloqueia quaisquer novas ligações.

    O problema tem um impacto crítico para os clientes que utilizam uma firewall com estado, uma vez que torna a funcionalidade Lista de negações (Denylist) inutilizável. Uma vez ativada a funcionalidade Lista de negações (Denylist), os Eventos de firewall (Firewall Events) são preenchidos com os registos: “FLOOD_ATTACK_DETECTED” e “Origem da lista de bloqueio: xxx.xxx.x.x excedeu o limite CPS: 0 por origem” (Blacklisting source: xxx.xxx.x.x exceeded CPS limit: 0 per source).  Em que o endereço IP é o endereço IP de gestão do Edge e CPS = Ligações por segundo. O novo limite de Limiar de novas ligações está a ser definido para 0%, o que significa que quaisquer tentativas de ligação acionarão a lista de negações para bloquear todas as ligações.  O valor predefinido de Limiar de novas ligações é de 25%.

  • Problema 58282 resolvido: só são permitidos fluxos destinados a um intervalo de IP privado que corresponde ao caminho predefinido, se uma política empresarial estiver configurada com o serviço de Rede como “Direto” (Direct) e o encaminhamento de ligação como “Obrigatório” (Mandatory).

    Os pacotes para um intervalo IP privado serão ignorados no VMware SD-WAN Edge se este corresponder ao caminho predefinido e se o destino for Multicaminhos (Multipath). Se o destino for Direto (Direct), os pacotes não deverão ser ignorados. Mas os pacotes só serão permitidos se o encaminhamento de ligação estiver configurado como “Obrigatório| (Mandatory) na política empresarial.

  • Problema 58527 resolvido: ao executar o diagnóstico remoto “Listar fluxos ativos” (List Ative Flows), a saída do nome da política empresarial está limitada a 24 caracteres em comparação com os 32 esperados e o nome da política empresarial é cortado para 24 caracteres dos 32 caracteres reais.

    Em .edge.info, o nome biz_policy configurado está listado corretamente (mesmo que ocupe todo o comprimento no campo biz_policy_name). Mas ao apresentar o biz_policy_name na saída user_flow_dump/flow_dump, estamos a utilizar apenas 24 caracteres para armazenar o nome da política. Desta forma, o biz_policy configurado real, não é completamente apresentado.

  • Problema 58567 resolvido: num local configurado com uma topologia de Alta Disponibilidade onde os VNFs também estão configurados, podem ocorrer recuperações automáticas de HA frequentes devido ao VNF estar desativado.

    Quando um VNF de Ponto de Verificação é implementado com HA, o VMware SD-WAN Edge monitoriza o estado do VNF utilizando consultas SNMP. Se o estado VNF for assinalado como desativado em 3 tentativas consecutivas, o Edge determinará que o VNF está desligado e iniciará uma comutação HA. O problema é que, uma vez que um VNF de Ponto de Verificação pode demorar mais de 1 segundo a responder a consultas SNMP de forma intermitente, o Edge pode tirar conclusões erradas quanto ao estado do VNF de Ponto de Verificação e assinalá-lo como desativado quando estiver ativado e cometer este erro várias vezes provocando recuperações automáticas da HA frequentes.

    Sem a correção, a única forma de resolver este problema é aumentar o número de novas tentativas do SNMP para um valor superior a 3 antes de determinar que o VNF está inativo. Isto pode ser configurado em /opt/vc/etc/vnf/default.json modificando o campo “snmp_retries” e desligando e ligando o VNF.

  • Problema 58678 resolvido: se o Edge a Edge Dinâmico estiver ativado e uma mensagem de controlo do Edge a Edge Dinâmico inválido for recebida num VMware SD-WAN Edge, o Edge poderá sofrerá uma falha do Serviço dataplane.

    Para criar um túnel para o par Edge, o Edge solicita informações ao Edge a Edge Dinâmico a partir do VMware SD-WAN Gateway. Se a mensagem de resposta do Gateway estiver corrompida, isto poderá fazer com que o Edge reinicie, uma vez que a validação correta está em falta em alguns dos campos.

  • Problema 58830 resolvido: o VMware SD-WAN Edge está a ignorar tráfego de um cliente encaminhado para um servidor VCMP com a sub-rede NAT global no Gateway de parceiro.

    O ping de um cliente encaminhado para Edge para o tráfego VCMP falha. O ping falha no cenário listado, onde um caminho estático predefinido anunciado de um Gateway de parceiro para um Edge e o próprio Edge têm configurado um caminho estático predefinido local que está direcionado para o próximo hop do switch L3 de underlay para acessibilidade do cliente encaminhado. Neste caso, o Edge ignora o pacote de resposta ICMP a partir do VCMP com o erro “correspondência de caminho de cloud rfc1918” (rfc1918 cloud route match).

  • Problema 58985 resolvido: quando as sessões BGP e BFD são configuradas com o mesmo local_ip. Se o local_ip BFD/BGP for alterado, a outra sessão que está a utilizar o local_ip ficará inativa.

    O BGP e o BFD utilizam tabelas local_ip separadas. Quando a configuração do BFD local_ip é modificada, o local_ip BFD é verificado. Dado que o BFD já não utiliza o endereço IP, a entrada correspondente é removida da tabela local_routes comum (utilizada pelo BGP e pelo BFD), o que afeta o BGP, dado que ainda está a utilizar o local_ip. A correção garante que quando o local_ip BFD/BGP for atualizado, é realizada uma verificação para detetar se outros processos ainda estão a utilizar o local_ip.
    Se estiver a ser utilizado, a remoção será ignorada.

  • Problema 59008 resolvido: a ligação internaID para várias ligações USB pode ser a mesma entre vários VMware SD-WAN Edges, o que provoca estatísticas de ligação USB incorretas no VMware SD-WAN Orchestrator.

    As ligações USB em diferentes Edges podem ter o mesmo ID interno atribuído. Como resultado, a monitorização entre diferentes Edges de um cliente é afetada, uma vez que alguns dados serão perdidos.

  • Problema 59527 resolvido: numa configuração no local com uma topologia de Alta Disponibilidade e onde os VNFs também são implementados na HA, um cliente pode sofrer interrupções repetitivas devido à recuperação automática da HA ocorrer repetidamente.

    Quando um VNF HA está ativo e todas as ligações secundárias de LAN ficam inativas para ambos os Edges, este problema é acionado e continuará até que a conetividade LAN seja restaurada em, pelo menos, um dos Edges do par HA.

  • Problema 59820 resolvido: um Spoke Edge do VMware SD-WAN pode formar um túnel com um Edge Hub principal degradado em alguns cenários.

    Este problema é visto em cenários de interoperabilidade nos quais o Spoke Edge executa uma versão 3.X e o Edge Hub e o VMware SD-WAN Gateway executam uma versão 4.X. As mensagens de controlo DCE são mal interpretadas, o que resulta no Spoke Edge formar um túnel com o Edge Hub Principal degradado. Isto deve-se a uma formatação incorreta da mensagem DCE enviada para o Spoke Edge pelo Gateway.

  • Problema 59862 resolvido: ao executar o Diagnóstico Remoto “Estado da interface” (Interface Status), o teste pode falhar com a mensagem “Erro de leitura dos dados de teste” (Error Reading data for test).

    O problema é provocado por uma entrada de modem USB que é deixada para trás no ficheiro de configuração de rede do VMware SD-WAN Edge depois de inserir e, em seguida, remover um modem USB. A correção deste problema garante que os dados isolados são tratados de forma adequada e o teste funciona corretamente. Em Edges que não têm a correção, um reinício do Edge limpa a entrada extraviada e o teste será executado corretamente.

  • Problema 60006 resolvido: quando a HA estiver ativada nos VMware SD-WAN Edges baseados em hardware, por exemplo, o 620 e o 640, o Edge em espera pode reiniciar de forma intermitente.

    Quando a HA estiver ativada num 620 ou 640, o Edge em espera pode detetar uma emergência Ativo/Ativo e reiniciar para recuperar do estado Ativo/Ativo.

  • Problema 60130 resolvido: um local pode experimentar 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.

    Esta correção soluciona problemas com o valor em cache dos endereços MAC num fluxo (a causa mais comum do problema). No entanto, não corrige um cenário mais raro em que o ARP se coloca em cache e, em seguida, devolve um MAC zero. Este problema será resolvido no 62552. Além de ter uma imagem do Edge com a correção, não há solução para este problema.

  • Problema 60225 resolvido: ao executar o Diagnóstico Remoto de “Estado de interface” (Interface Status) de um VMware SD-WAN Edge, a saída no VMware SD-WAN Orchestrator para interfaces SFP mostra as informações duplex e de velocidade incorretas.

    Os dados no Orchestrator estão incorretos para interfaces SFP. Por exemplo, apresentar 0 Mbps/half-duplex em que, se visto diretamente no Edge, os dados mostram full duplex a 1000 Mbps ou algo similar.

  • Problema 60523 resolvido: o ping falhará para um endereço IP de cliente encaminhado se uma sonda SLA estiver ativada.

    O pacote de resposta ICMP falha o processamento do Serviço dataplane Edge se uma sonda SLA estiver ativada para o endereço IP do cliente encaminhado.  Sem a correção, a única forma de resolver esta situação era desativar a pesquisa ICMP.

  • Problema 61388 resolvido: o caminho SNP utilizado para o intercâmbio de BGP está a ser anunciado para Edges remotos se esse prefixo for recebido a partir de qualquer par BGP.

    Se o cliente anunciar o local_ip utilizado para o intercâmbio de BGP através do BGP, isso criará um caminho estático do centro de dados para o mesmo prefixo anunciado a outros pares em vez de um caminho dinâmico de BGP.

  • Problema 61400 resolvido: numa empresa do cliente onde o Edge a Edge através do Gateway ou o Edge a Edge Dinâmico estão ativados, quando um utilizador envia pacotes ICMP, podem observar dois valores de MTU diferentes.

    Se um utilizador definir o valor interface MTU e enviar pacotes para o VMware SD-WAN Edge com o DF bit definido, o Edge poderá devolver duas mensagens de erro ICMP diferentes com dois valores de MTU diferentes. O valor diferente representa a interface MTU versus o túnel MTU.  Este é um problema de origem e não tem impacto no cliente.

  • Problema 61433 resolvido: numa topologia de Hub/Spoke em cascata onde um VMware SD-WAN Edge é um Spoke para um cluster de Hub e também um Hub para outro Spoke, as alterações de routing de underlay num dos membros do cluster de Hub podem eliminar os caminhos deste Edge Spoke/Hub.

    Em caso de uma topologia de Hub em cascata, a remoção do caminho num membro do cluster de Hub acionou uma mensagem de eliminação não intencional do VMware SD-WAN Gateway para o Spoke Edge que também serve como um Edge Hub. Esta mensagem deveu-se a uma atualização no Spoke profundo, que deveria ter sido ignorada no Gateway, mas devido a este problema, o Gateway enviou uma mensagem de eliminação para o Edge Hub/Spoke, o que resultou no Edge perder os caminhos de underlay (aprendidos a partir do cluster do Hub).

    Sem a correção nesta versão, não existe uma solução alternativa para este problema relacionado com uma topologia de Hub em cascata. É aconselhado evitar tornar um Edge num Spoke para um Cluster de Hub e também um Hub para um Spoke profundo, caso contrário este problema pode surgir.

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

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

  • Problema 61596 resolvido: existe uma degradação do desempenho quando o BGP de parceiro é ativado com a opção segura e um caminho estático é configurado como não seguro ou vice-versa.

    A degradação do desempenho é provocada por um erro de cálculo do comprimento máximo do endereço IP quando um caminho estático não seguro recolhe o sinalizador seguro a partir de uma configuração BGP. Inicialmente, o VMware SD-WAN Gateway faz uma pesquisa de caminho e, se encontrar um caminho estático inseguro, o Gateway verificará se o BGP está ativado ou não.  Se o BGP estiver ativado, o Gateway verificará a encriptação definida e, em seguida, recolherá a encriptação definida para o BGP, que é seguro, e a fragmentação ocorrerá porque a opção segura é mais conservadora do que insegura.

  • Problema 61739 resolvido: o VMware SD-WAN Edge está a reportar o endereço IP incorreto ao VMware SD-WAN Orchestrator, que resulta em páginas de Monitorização que mostram o endereço IP errado.

    Isto pode ser visto em Monitor > Edge > Sources/Destinations (Monitor > Edge >Origens/Destinos) e em Eventos do Edge para eventos de novo dispositivo cliente. Um dispositivo cliente ligado ao Edge que tenta aumentar o tempo de concessão, enviará um pacote que solicita o aumento da concessão e assim que o Edge receber este pacote, o IP de origem do dispositivo cliente ficará invertido no separador Origem (Source) na página Monitorizar (Monitor). É entendido como uma questão estética e não afeta qualquer funcionalidade subjacente para além da confusão sobre os dados imprecisos.

  • Problema 62004 resolvido: o VMware SD-WAN Edge reporta elevada utilização da memória para o VMware SD-WAN Orchestrator, mesmo que a utilização real da memória dos processos em execução no Edge seja baixa.

    O Edge calcula a utilização da memória do sistema lendo o ficheiro /proc/meminfo. O cálculo exclui a memória livre, memórias intermédias e a memória em cache da memória total para obter a utilização da memória. O Edge não exclui a memória recuperável da secção da memória total e, portanto, a utilização da memória reportada poderá ser por vezes elevada se a memória recuperável for elevada.  Isto faz com que os utilizadores vejam números de utilização de memória elevados para um Edge que, na verdade, não são válidos.

  • Problema 62620 resolvido: num local implementado com uma topologia de Alta Disponibilidade, o tráfego direto para alguns dos destinos pode parar de funcionar após a recuperação automática de HA.

    Os fluxos do VMware SD-WAN Edge ativo são sincronizados para o Edge em espera, juntamente com a porta alocada para a entrada NAT para que, quando ocorra uma recuperação automática, não exista nenhuma perturbação no tráfego após a recuperação automática. A porta alocada no Edge em espera nunca é libertada mesmo depois de o fluxo expirar. Assim, quando existe uma recuperação automática, existe a possibilidade de exaustão de porta NAT e de falha de NAT. Como resultado, podem ser ignorados pacotes no Edge.

  • Problema 62890 resolvido: os IDs da aplicação são diferentes ao visualizar as estatísticas no Edge Network Intelligence e no VMware SD-WAN Orchestrator.

    Há duas formas diferentes de aprender as aplicações:
    1. No primeiro pacote, através de uma base de dados de portas e endereços IP de aplicações SaaS bem conhecidas (por exemplo, Office 365) ou através da aprendizagem do IP de uma aplicação que o Orchestrator tinha aprendido anteriormente.
    2. Após uma série de pacotes serem analisados com a inspeção de pacotes profunda (DPI).

    Os IDs de Aplicação do Edge Network Intelligence não estavam a ser atualizados por #2. Isto significa que as aplicações do primeiro pacote, como Office365, são visíveis, mas as aplicações que exigem DPI (por exemplo, AnyDesk) são vistas no Orchestrator, mas não no Edge Network Intelligence.

Problemas resolvidos do Orchestrator

Versão R430-20211221-GA do Orchestrator

A versão R430-20211221-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.

    ___________________________________________________________________

    Versão R430-20211112-GA do Orchestrator

    A versão R430-20211112-GA do Orchestrator foi lançada a 16-11-2021. Esta compilação do Orchestrator não adiciona novos problemas corrigidos desde a versão R430-20210810-GA do Orchestrator, mas contém alterações de desempenho e resolução de problemas exigidas pela VMware Engineering.

      ___________________________________________________________________

      Resolvido na versão R430-20210810-GA do Orchestrator

      A versão R430-20210810-GA do Orchestrator foi lançada a 12-08-2021 e resolve um novo problema crítico desde a versão R430-20210729-GA 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 Grupos de objetos (Object Groups) é 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 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 esteja 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. 

      ___________________________________________________________________

      Resolvidos na versão R430-20210729-GA

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

      • 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 68577 resolvido: um VMware SD-WAN Orchestrator atualizado para a versão 4.3.0 pode ter uma IU com funcionalidades danificadas e predefinições de IPv6 em falta.

        A IU do Orchestrator não permitirá que o utilizador carregue perfis e outras definições não serão guardadas, com a página da Web do Orchestrator pendente indefinidamente. Este problema ocorrerá se for detetada uma configuração inválida pelo Orchestrator durante a atualização que desencadeie uma “falha na aplicação de patch” (será notada nos eventos do Orchestrator). Quando uma configuração inválida desencadeia a falha de patch, as configurações restantes na fila de entrega do patch são ignoradas, incluindo o objeto IPv6.  A IU do Orchestrator não carrega a página devido à suposição do objeto relacionado com o IPv6 em falta a preencher.

      ___________________________________________________________________

      Resolvidos na versão R430-20210719-GA

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

      • Problema 66203 resolvido: um Administrador de parceiros não consegue editar os handoffs do Gateway de parceiro para um cliente a quem é atribuído um conjunto de Gateways que inclui os Gateways geridos pelo parceiro e Gateways alojados na cloud num VMware SD-WAN Orchestrator.

        Os handoffs do Gateway são configurados na página Configurar > Cliente (Configure > Customer) do Orquestrador. Quando um conjunto de Gateways misto é atribuído a um cliente que contenha Gateways geridos pelo parceiro e Gateways alojados na cloud (Gateways geridos pela VMware), o Administrador de parceiros não consegue modificar a configuração de handoff do Gateway para os Gateways geridos.

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

      ___________________________________________________________________

      Resolvidos na versão R430-20210709-GA

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

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

      ___________________________________________________________________

      Resolvido na versão R430-20210615-GA

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

      • Suporte para VMware SD-WAN Edge modelos 510N, 610N, 620N, 640N e 680N.

        A compilação R430-20210615-GA do Orchestrator suporta os modelos Edge 510N, 610N, 620N, 640N e 680N. Estes modelos não incluem Wi-Fi integrado. Para obter mais detalhes, consulte a secção Suporte para novas plataformas de hardware acima nas Notas de versão. 

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

      ___________________________________________________________________

      Resolvido na versão R430-20210527-GA

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

      • Problema 20900: se o serviço de geolocalização MaxMind estiver ativado e não conseguir contactar o servidor MaxMind, as novas ativações VMware SD-WAN Edge não funcionarão.

        O Edge cria uma ligação HTTPS ao VMware SD-WAN Orchestrator para o ativar. O tempo limite predefinido para o pedido é de 120 segundos e para a ligação de proxy, é de 60 segundos. Dado que o Orchestrator está a tentar geolocalizar o Edge (endereço remoto IPv4), as transferências aguardam a resposta a partir do serviço MaxMind para prosseguir com a ativação. Assim, após 60 segundos, o NGINX para obter a resposta do serviço de transferência e fecha a ligação. Por conseguinte, a ativação falha devido a um 504 tempo limite excedido do NGINX. 

        Com a nova propriedade do sistema service.maxmind.timeout.seconds, a chamada de API Maxmind é realizada com um tempo limite personalizado. Se o tempo limite for atingido, a chamada prosseguirá com o fluxo de trabalho de ativação e, por isso, o Edge será ativado com sucesso.

      • Problema 29701 resolvido: um utilizador pode configurar o endereço IP da interface encaminhada com um formato de ID de rede ao utilizar a IU do VMware SD-WAN Orchestrator.

        O Orchestrator não verificará nem apresentará nenhum erro se o utilizador configurar um endereço IP de uma interface encaminhada com um formato de tipo de ID de rede (por exemplo, “1.2.3.0”). Se este erro não for corrigido, poderá provocar problemas no fluxo de tráfego do cliente. A correção para este problema garante que a validação é realizada para o endereço IP da interface encaminhada e lança um erro se o formato não estiver correto.

      • Problema 30066 resolvido: na página Gateway do cliente, o cliente verá a contagem de Gateway de parceiro como zero, apesar de ter um Gateway de parceiro atribuído. 

        O VMware SD-WAN Orchestrator utiliza o parâmetro errado para determinar se um Gateway de parceiro está atribuído. Como resultado, a condição é sempre apresentada como falsa e a contagem é indicada como zero.  A correção utiliza o parâmetro correto para verificar se o Gateway de parceiro está atribuído e garante que é apresentada a contagem do Gateway de parceiro correta.

      • Problema 31416 resolvido: as atualizações de configuração demoram mais de seis minutos a concluir em empresas de cliente de grande dimensão e, como resultado, podem ultrapassar o tempo limite. 

        Uma empresa de cliente de grandes dimensões é compreendida como tendo pelo menos 16 segmentos, 50 Edges Hub e 10 000 Spoke Edges onde o utilizador atribuiria um perfil spoke aos 10 000 Spoke Edges e um perfil de hub para os 50 Hub Edges e o Edge-a-Edge é configurado através de 5 Hub Edges em cada segmento do perfil Spoke.  Numa empresa deste género, uma atualização de configuração pode demorar tanto tempo que o tempo limite é ultrapassado e tem um impacto significativo na capacidade dos administradores de configurarem a sua rede. A correção garante que mesmo as empresas desta dimensão conseguem concluir com sucesso quaisquer atualizações de configuração, independentemente da dimensão.

        Sem a correção, a única forma de evitar tempos excedidos na IU é ativar a API Assíncrona (session.options.asyncPollingMaxCount: 50) ou definir vco.enterprise.events.configuration.diff.enable para Falso. Este último desativa os eventos diff de configuração, mas melhora o desempenho geral de qualquer API relacionada com a configuração.

      • Problema 33026 resolvido: quando um utilizador elimina um Acordo de Serviços de Utilizador Final (EUSA) da página de Acordos do Utilizador na IU do VMware SD-WAN Orchestrator, a página não atualiza corretamente.

        Quando o utilizador elimina a última entrada do EUSA, a página tem de ser atualizada, mas o Orchestrator não aciona a atualização. A correção reescreve a lógica de validação para a atualização da página para garantir o resultado esperado.

      • Problema 38536 resolvido: o utilizador não consegue eliminar um VMware SD-WAN Edge quando utiliza o VMware SD-WAN Orchestrator com o erro “Erro ao processar o item. Tente novamente” (Error processing item. Please try again).

        Este problema ocorre porque a atribuição de rede para um Edge não está presente na base de dados e isso interrompe o processo de eliminação do Edge.

      • Problema 39035 resolvido: para as empresas de cliente com um grande número de Edges, Perfis e Segmentos, quando um administrador tenta alterar o tipo de segmento, a aplicação da configuração pode demorar tanto tempo a concluir que o processamento ultrapassa o tempo limite e a alteração da configuração não é aplicada.

        Entende-se como uma grande empresa de cliente uma empresa com mais de 3000 Edges, com mais de 1000 Edges ativados num único perfil onde o Edge a Edge através do Gateway está ativado e cada Edge é configurado com 16 segmentos.  Nestas condições, uma alteração de segmento poderá não ser concluída na janela temporal necessária (6 minutos) e exceder o limite de tempo.

      • Problema 42243 resolvido: o utilizador não consegue editar uma regra de firewall que inclui um endereço IP e um nome de domínio.

        Uma vez criada uma regra de firewall com um endereço IP e um nome de domínio que é observável na página da Regra de Firewall, um utilizador não pode realizar alterações a esta regra.  Por exemplo, eliminar um nome de domínio vai lançar um erro “Corrija o problema abaixo e tente novamente” (Please fix the problem below and try again) em que o problema está em remover esse nome de domínio.

      • Problema 44755 resolvido: para um local que utiliza um VMware SD-WAN VNF Edge em que o Edge está ligado e a inserção VNF foi realizada, se um utilizador transferir um CSV da lista Edge > Monitorizar, o CSV mostrará o estado incorretamente como “Ligado (Inserção não ativada)” (Powered On (Insertion Not Enabled)).

        O problema só afeta o relatório CSV transferido.  A IU do VMware SD-WAN Orchestrator apresentará o estado correto “Ligado (Inserção ativada)” (Powered On (Insertion Enabled)) para um Edge VNF ativado desta forma.

      • Problema 45293 resolvido: se a opção da VLAN “Resposta de eco ICMP” (ICMP Echo Response) for desligada num VMware SD-WAN Edge utilizando a Anulação de Edge (Edge Override) e, posteriormente, a própria Anulação de Edge (Edge Override) for desligada, o que deverá forçar o Edge a utilizar as definições de perfil para esta opção, o Edge não aceitará a definição “Resposta de eco ICMP” (ICMP Echo Response) do perfil, e essa opção permanecerá desligada mesmo que o perfil tenha a opção ligada.

        Isto tem impacto sobre um cliente que está à espera que uma VLAN do Edge em particular envie um ping de volta ao pacote ICMP e o VMware SD-WAN Orchestrator indica que está configurado para o fazer, dado que o Edge deve estar a extrair a configuração do Perfil. 

      • Problema 46254 resolvido: um VMware SD-WAN Edge recentemente ativado pode não ter definições DHCP e VLAN em uma ou mais interfaces encaminhadas.

        O URL de ativação de e-mail deve incluir toda a configuração específica do Edge que o utilizador criou para esse Edge no momento em que o e-mail de ativação foi enviado. Com este problema, se o Edge tiver definições VLAN numa interface ativada por DCHP, a ligação de e-mail poderá não incluir as configurações de DHCP e de VLAN para o Edge e, quando o Edge for ativado, o utilizador observará estas definições em falta para esse Edge no VMware SD-WAN Orchestrator.

      • Problema 46996 resolvido: quando um utilizador muda um VMware SD-WAN Edge de um perfil para outro, utilizando o VMware SD-WAN Orchestrator, o ecrã do browser pode congelar e exigir uma atualização do browser para continuar.

        O ecrã da IU do Orchestrator ficará cinzento após confirmar o interruptor de perfil ao utilizar Configurar > Edges (Configure > Edges) e apenas permanece dessa forma até que a atualização seja realizada.  A ação para alterar o perfil é, de facto, bem-sucedida e pode ser confirmada assim que a atualização do browser for realizada. 

      • Problema 47990 resolvido: os utilizadores não conseguem ver a opção “Interface” enquanto configuram um caminho estático no VMware SD-WAN Orchestrator.

        Se um utilizador configurar uma interface VLAN com um endereço IP e, posteriormente, remover o endereço IP, quando tenta criar um caminho estático, o Orchestrator ainda considera que o caminho é para uma interface VLAN e não permitirá que o utilizador selecione a opção “Interface” para a entrada do caminho estático. O utilizador ainda consegue guardar a configuração e o caminho aparecerá na tabela de routing, mas o sinalizador de acessibilidade aparecerá como FALSO.

      • Problema 48068 resolvido: um Operador com uma função Empresarial tem a opção de eliminar um VNF, mesmo que o VNF esteja em utilização.

        O resultado da eliminação do Operador Empresarial de um VNF em utilização fará com que o Orchestrator apresente uma mensagem “Ocorreu um erro inesperado” (An Unexpected Error Has Occurred) na IU.

      • Problema 48131 resolvido: se um Operador com uma função Empresarial iniciar sessão na instância em espera de um VMware SD-WAN Orchestrator configurado para utilizar a Recuperação após Desastre (DR), a página do browser será apresentada como a carregar, mas na realidade nunca será carregada.

        Nem mesmo uma atualização de browser limpará este problema. A correção para este problema inclui uma mensagem de erro a indicar ao Operador com uma função Empresarial que deve iniciar sessão na instância correta do Orchestrator (isto é, a instância Ativa do par).

      • Problema 48459 resolvido: um administrador de cliente com uma função de Apoio ao cliente não conseguirá ver a secção ID de autenticação local de um Destino Não-SD-WAN (NSD) num VMware SD-WAN Orchestrator.

        O utilizador do apoio ao cliente consultará a secção Configurar > Serviços de rede (Configure > Network Services) do Orchestrator para examinar os detalhes de NSD. O problema é o resultado do código em falta para apresentar os detalhes de ID de autenticação local no ficheiro só de leitura do Orchestrator.  A correção adiciona o código e ficheiros correspondentes para apresentar o ID de autenticação local no modo só de leitura para os utilizadores de apoio ao cliente.

      • Problema 48461 resolvido: se um utilizador desligar os Alertas ao nível do Edge, a configuração não será cumprida para os alertas de túnel de Serviço de Segurança Informática (CSS).

        Os alertas podem ser desligados de um VMware SD-WAN Edge em particular avançando para Configurar > Edge > Descrição Geral (Configure > Edge > Overview) e desmarcando a caixa Ativar alertas (Enable Alerts). A expectativa quando esta caixa é desmarcada é que o Edge não envie quaisquer alertas de qualquer tipo e por qualquer motivo. No entanto, se o Edge estiver configurado para utilizar um CSS, os utilizadores configurados para receber alertas deverão recebê-los para eventos de túnel CSS neste Edge (isto é, túnel CSS ativo ou inativo).

      • Problema 48633 resolvido: um administrador de cliente com uma função de Apoio ao cliente não conseguirá ver vários detalhes de configuração de um Destino Não-SD-WAN (NSD) num VMware SD-WAN Orchestrator.

        Isto é virtualmente idêntico ao 48459, mas abrange parâmetros diferentes de uma configuração NSD, incluindo o nome de utilizador e o nome de anfitrião. O utilizador do apoio ao cliente consultará a secção Configurar > Serviços de rede (Configure > Network Services) do Orchestrator para examinar os detalhes de NSD. O problema é o resultado do código em falta para apresentar os detalhes de ID de autenticação local no ficheiro só de leitura do Orchestrator.  A correção adiciona o código e ficheiros correspondentes para apresentar o ID de autenticação local no modo só de leitura para os utilizadores de apoio ao cliente.

      • Problema 48641 resolvido: um Operador com uma função de Suporte é incapaz de ver o “Modo de autenticação do Gateway” (Gateway Authentication Mode) do VMware SD-WAN Gateway na página Gateways da IU do VMware SD-WAN Orchestrator.

        Dado que um Operador do suporte é só de leitura para configurações, ocorreu uma falha que permitiu que um Operador conseguisse, pelo menos, visualizar o Modo de Autenticação do Gateway, quando apenas os Operadores com privilégios de configuração deveriam conseguir ver este campo.

      • Problema 48642 resolvido: um operador com uma função de Suporte não consegue visualizar o campo “Licença” (License) na secção Configurar > Edge > Visão geral do Edge (Configure > Edge > Edge Overview) do VMware SD-WAN Orchestrator.

        Anteriormente não existia nenhum código para visualizar o campo Licença (License) no modo só de leitura, o que significava que os Operadores do suporte não conseguiam ver o campo. Com esta correção, o campo Licença (License) também pode ser visto no modo só de leitura.

      • Problema 48645 resolvido: um operador com uma função de suporte é capaz de configurar o campo “Depreciado” (Deprecated) numa Imagem de Software do Edge.

        Se um Operador do suporte navegar para a secção Imagens de software (Software Images) da IU do VMware SD-WAN Orchestrator, este poderá selecionar uma imagem do Edge para examinar e o campo “Depreciado” (Deprecated) deverá estar indisponível para esse Operador, dado que apenas tem privilégios só de leitura. Este problema é o resultado de uma falta de verificações de condição/validação para verificar se o Operador tem ou não privilégios para editar a caixa de verificação.

      • Problema 48915 resolvido: na página de Eventos do serviço de segurança na cloud (CSS) (Cloud Security Service (CSS) Events), o Tipo CSS não é apresentado corretamente.

        Os Eventos CSS encontram-se na página Serviços de rede (Network Services) do VMware SD-WAN Orchestrator.  O título da página apresenta código não processado (por exemplo, “UIPlugins.genericCloudSecurityService.title”) em vez da cadeia do título real. A correção adiciona uma cadeia de título para o código não processado que foi previamente apresentado.

      • Problema 49395 resolvido: um VMware SD-WAN Edge apresenta um carimbo de data/hora de systemUpSince a partir do momento em que o dispositivo é aprovisionado pela primeira vez e não a partir do momento em que o Edge é ativado pela primeira vez.

        O problema pode ser visualizado selecionando o menu pendente de informações do Edge em Monitorizar > Edges > Visão geral do Edge (Monitor > Edges > Edge Overview). O tempo de systemUpSince indicado antes da ativação do Edge não tem significado e prejudica a resolução de problemas do Edge.

      • Problema resolvido 49997: se o modo de análise do VMware Edge Network Intelligence estiver ativado num VMware SD-WAN Orchestrator, quando um novo utilizador operador for criado, o operador não será capaz de se ligar às secções de análise da IU do Orchestrator.

        Os utilizadores operadores criados após a ativação do modo de análise devem conseguir aceder à IU do VMware Edge Network Intelligence de todos os clientes empresariais que tenham ativado o acesso de suporte e este não é o caso com este problema.

      • Problema 50082 resolvido: ao alterar o tempo de concessão DHCP através da API ou modificando os valores na IU do VMware SD-WAN Orchestrator através do elemento de inspeção interrompe a IU do Orchestrator, dado que a IU apenas suporta valores predefinidos de 900, 3600, 14400, 43200, 86400 e 604800.

        Esta questão pode ser vista utilizando os seguintes passos:

        1. Criar um novo perfil.
        2. Altere o tempo de concessão VLAN DHCP predefinida para algo diferente de 900, 3600, 14400, 43200, 86400 e 604800.
        3. Atribua esse perfil a um Edge.
        4. Selecione o botão “Editar” (Edit) do VLAN dentro do Edge.
        5. Não acontece nada.

        A correção adiciona uma validação para o tempo de concessão do DHCP, dado que deve ser um destes valores [900, 3600, 14400, 43200, 86400 e 604800].  Não será permitido ao utilizador criar um perfil com um valor do tempo de concessão DHCP inválido através da API ou da IU do Orchestrator.

      • Problema 51608 resolvido: o “Teste DNS” (DNS Test) do diagnóstico remoto não aceita um nome de domínio com um carácter de sublinhado “_”.

        Ao tentar introduzir um nome de domínio com um símbolo de sublinhado (por exemplo, _test.com) para o Teste de DNS, o VMware Orchestrator devolverá um erro de leitura: “_test.com é inválido” (_test.com is invalid).  A correção adiciona um símbolo de sublinhado para validação do nome de domínio.

      • Problema 51620 resolvido: a interface VMware SD-WAN Edge não é reposta para “nenhum” (none) para os caminhos estáticos quando uma porta comutada é convertida para uma interface encaminhada.

        O problema ocorre após alterar o modo de interface de encaminhado para comutado e a reposição do menu pendente de caminho estático não ocorre. A correção aciona a funcionalidade de menu pendente de reposição nas alterações do modo de interface.  Este problema não é visto quando se altera de comutado para encaminhado.

      • Problema 51707 resolvido: quando um utilizador configura uma VLAN sem nome, o VMware SD-WAN Orchestrator apresentará o erro errado.

        O Orchestrator está a apresentar: o erro “O nome não deve conter < nem >” (name must not contain < and >), em vez do erro correto: “O nome é obrigatório para a VLAN” (Name is required for VLAN), ao criar uma VLAN sem nome.

      • Problema 51714 resolvido: um utilizador é capaz de configurar o campo “Compensação de tempo” (Time offset) em DHCP como um valor decimal, o que faz com que o dnsmasq falhe.

        Num VMware SD-WAN Orchestrator, o utilizador pode aceder às definições Configurar > Edge > Dispositivo (Configure > Edge > Device), selecionar uma interface encaminhada onde ativa o DHCP e, nas opções, adicionar um Compensação de tempo com um valor de, por exemplo, 0,11 e guardar essas alterações. O utilizador pode consultar a página Eventos (Events) e observar o seguinte: ‘“nsmasq observado[20245]: erro de FALHA no arranque”.  A correção inclui uma verificação de validação para garantir que as casas decimais não são permitidas no campo “Compensação de tempo” (Time offset).

      • Problema 52034 resolvido: o utilizador é capaz de configurar um valor não inteiro para a Porta IU local no VMware SD-WAN Orchestrator.

        Isto pode ser encontrado na página Configurar > Firewall (Configure > Firewall) para um Edge ou Perfil na secção “Acesso Edge” (Edge Access).  Um utilizador poderia configurar um valor não inteiro, por exemplo, 99,99 para a Porta Local de IU e o Orchestrator não lançaria um erro e aceitaria o valor. O impacto sobre o cliente foi atenuado porque o dataplane Edge estava a processar este parâmetro em que, na eventualidade de um valor não inteiro, atribuiria a porta 443 predefinida.  A correção agora inclui uma validação para este valor, para garantir que se trata de um número inteiro.

      • Problema 52107 resolvido: um Operador com uma função de Suporte é incapaz de ver o campo da região para uma configuração VNF num VMware SD-WAN Orchestrator.

        O Operador do suporte ao visualizar a caixa Configuração de gestão de serviço VNF (VNF Service Management Configuration) veria o campo Região (Region) como uma série de pontos de segurança. A correção permite que o campo Região (Region) seja visto como só de leitura.

      • Problema 52293 resolvido: a descrição de estado do túnel mostrará o nome de interface errado em Monitorizar > Destinos Não-SD-WAN via Edge (Monitor > Non SD-WAN Destinations via Edge) se existirem vários túneis.

        No VMware SD-WAN Orchestrator, quando o utilizador tem mais do que um túnel configurado num NSD via Edge, a IU apresenta o mesmo nome de interface para todos os túneis. O primeiro nome da interface está a ser copiado para todas as entradas.

      • Problema 52317 resolvido: os nomes de campo do Gateway de parceiro no módulo Conjunto de Gateways (Gateway Pool) na página Configuração do cliente (Customer Configuration) estão truncados.

        Se um utilizador Parceiro ou Operador aceder a Configurar > Cliente (Configure > Customer) num VMware SD-WAN Orchestrator e se deslocar até Conjunto de Gateways (Gateway Pool), o utilizador verá, em vez do nome do Gateway de parceiro, um nome truncado apresentado (por exemplo, “Pa...” e “C...”). 

      • Problema 52329 resolvido: na Nova IU do VMware SD-WAN Orchestrator, o gráfico circular na Vista de cliente (Customer View) não apresenta quaisquer valores numéricos quando um utilizador paira sobre o mesmo, como seria nos gráficos circulares na página Visão geral do Edge (Edge Overview).

        O utilizador não consegue ver o número de itens de um estado específico quando paira sobre uma série de gráficos circulares Total de clientes e Total de Edges.

      • Problema 52379 resolvido: o VMware SD-WAN Orchestrator enviará um e-mail de alerta “Edge Inativo” (Edge Down) se o VMware SD-WAN Edge recuperar dentro do intervalo de tempo configurado.

        Os administradores podem ser falsamente alertados que um Edge está inativo na sua rede, mesmo que tenham configurado um intervalo para permitir que um Edge fique inativo durante um determinado período de tempo antes de acionar esse alerta.

      • Problema 52729 resolvido: ao configurar um VNF, se o utilizador não incluir os valores corretos para os campos obrigatórios, a IU do VMware SD-WAN Orchestrator apresentará “Ocorreu um erro inesperado” (An unexpected error has occurred) sem indicar qualquer orientação sobre quais os campos que precisam de ser configurados.

        Um utilizador pode indicar um nome de anfitrião inválido e a mensagem de erro será apenas “Ocorreu um erro inesperado” (An unexpected error has occurred) em vez de indicar explicitamente que o nome anfitrião é inválido. A correção adiciona uma validação adequada para estes campos VNF e mensagens de erro mais explícitas.

      • Problema 52820 resolvido: nos VMware SD-WAN Orchestrators com um grande número de VMware SD-WAN Edges, uma alteração de configuração realizada através da IU pode resultar no lançamento do erro de tempo limite excedido.

        Se um pedido de configuração não for comunicado ao Orchestrator dentro de 90 segundos, será apresentado o erro de tempo limite excedido.  A correção efetua a gestão de Orchestrators de grande dimensão (pelo menos, 2000 Edges) configurando automaticamente um sistema API assimétrico.

      • Problema 52835 resolvido: num VMware SD-WAN Orchestrator que utiliza a Nova IU, o nome de serviço do túnel dos Destinos Não-SD-WAN via Edge não estão a atualizar corretamente no ecrã Monitorizar Edge (Monitor Edge).

        Quando um utilizador abre a lista Monitorizar > Edges (Monitor > Edges), o utilizador verá um nome de serviço técnico na descrição da coluna “Túneis Edge” (Edge tunnels) em vez de um nome de apresentação amigável. Por exemplo, nome de túnel dos Destinos Não-SD-WAN via Edge “Router IKEv2 genérico” (Generic IKEv2 router) está a atualizar erradamente como “Router ik v2 genérico” (Generic ik v2 router).

      • Problema 52851 resolvido: um evento de ativação do VMware SD-WAN Gateway é apresentado na IU do VMware SD-WAN Orchestrator com uma descrição incorreta a indicar: “Ativação do Edge” (Edge activation).

        Isto é visto nos Eventos do Operador sempre que um novo Gateway é ativado.

      • Problema 52863 resolvido: a IU do VMware SD-WAN Orchestrator permite configurações do temporizador BGP não padrão e não apresenta nenhum erro.

        Ao ativar a configuração de handoff de Parceiro na página de configuração do cliente, quando um utilizador configura temporizadores de retenção/suspensão de BGP no Orchestrator que não cumprem com a norma BGP em RFC 4271, o Orchestrator permite que a configuração seja guardada. No entanto, no próprio VMware SD-WAN Edge, o FRR altera os valores de retenção/suspensão para cumprir com as normas. Por exemplo, se um utilizador configurar um valor de retenção de 2 segundos/suspensão de 5 segundos no Orchestrator, o Edge FRR alterará o valor de retenção para 1 segundo, ou seja, 3 x o valor de retenção = (menor ou igual a suspensão).

      • Problema 52885 resolvido: um parceiro ou administrador de cliente é capaz de alterar a palavra-passe de início de sessão, preenchendo apenas o primeiro campo e não precisando de preencher o campo de confirmação.

        Isto é verdade para todas as funções de utilizador tanto ao nível de parceiro como de cliente.  O campo de confirmação foi concebido para impedir que um administrador pense que introduziu uma palavra-passe quando, na realidade, não era exatamente o que pretendia.

      • Problema 52903 resolvido: quando um utilizador tenta adicionar um fornecedor do novo serviço de segurança na cloud (CSS) sem o token API correto, a IU VMware SD-WAN do Orchestrator (VMware SD-WAN Orchestrator) devolve “Nome de utilizador ou palavra-passe inválido” (Invalid Username or password).

        Isto foi visto no CSS mais comum: Zscaler. Existem dois outros problemas associados a este pedido: os campos palavra-passe e token não são introduzidos quando estão em texto não encriptado.  E um token com o prefixo certo será tratado como o token correto, mesmo que não o seja. A correção para todos estes problemas é a validação melhorada das credenciais da API de CSS.

      • Problema 52918 resolvido: numa empresa de cliente que implementa pelo menos um VNF, se em algum momento os detalhes de implementação do VNF não corresponderem aos detalhes reais da implementação, um VMware SD-WAN Orchestrator que utiliza a Nova IU não emitirá nenhum aviso sobre a não correspondência.

        A IU antiga funciona corretamente neste cenário.  A mensagem de erro que deveria surgir indica “A implementação VNF atual não corresponde ao estado configurado para este Edge.  Isto acontece normalmente quando está pendente a aplicação de uma alteração recente pelo Edge e, geralmente, é resolvido após alguns ciclos de heartbeat.  Consulte os eventos do Edge para obter informações adicionais.”

      • Problema 52934 resolvido: a Automatização do Azure para Serviços de Rede ou Destino Não-SD-WAN via Gateway ou Destino Não-SD-WAN via Edge não será iniciada.

        O utilizador veria este problema ao configurar a adição/eliminação de NSD-via-GW ou NSD-via-Edge para o tipo Azure. O utilizador também pode ver que quando o IP de ligação WAN é alterado, a ação de atualização para o Azure não será processada.  Sem a correção, a única forma de corrigir este problema é reiniciar o processo de back-end do VMware SD-WAN Orchestrator.

      • Problema 53076 resolvido: o VMware SD-WAN Orchestrator permite que um utilizador introduza um número de telemóvel para a sua conta de administrador num formato numérico que não funciona corretamente.

        Este problema pode fazer com que um utilizador com autorização de dois fatores fique bloqueado, uma vez que o utilizador não conseguirá obter a mensagem de texto SMS necessária para concluir a 2FA. Se o número de telemóvel for introduzido no formato 00xxxxxxxx, o VMware SD-WAN Orchestrator não verificará campo e aceitará número. Aceita até números claramente errados, por exemplo “+-+00”. Mas quando alguém tenta iniciar sessão com esse utilizador, ocorre um erro: “O serviço SMS encontrou o seguinte erro:[objeto Objeto]” (The SMS service encountered the following error:[object Object]) Se o número for alterado para +<country_code>xxxxxxxxxx, funcionará corretamente.  A correção inclui uma verificação de validação para o número de telemóvel e o Orchestrator não permitirá números de telefone que não funcionem.

      • Problema 53428 resolvido: quando um utilizador configura duas empresas de cliente com o mesmo número de conta, o VMware SD-WAN Orchestrator apresenta uma mensagem de “Erro interno” (Internal error).

        Se um utilizador indicar um número de conta para uma empresa na página Definições do sistema (System Setting) e esse número de conta já existir para outra empresa, ao guardar as alterações, o erro interno será apresentado na IU. A mensagem de erro é vaga e não indica ao utilizador o que precisa de ser corrigido.  

      • Problema 53525 resolvido: ao utilizar a Nova IU num VMware SD-WAN Orchestrator e ao visualizar a página de visão geral do Edge, a coluna Ligações (Links) não apresenta o estado da ligação (por exemplo, Cópia de segurança, Em espera).

        Estas informações de estado de ligação são corretamente apresentadas na IU Antiga e com esta correção vão ser apresentadas conforme esperado na Nova IU.

      • Problema 53652 resolvido: quando uma empresa de cliente que está a utilizar um mapa de aplicação personalizado é atualizada de 3.x para 4.x, o cliente pode observar nomes aleatórios para as aplicações personalizadas criadas antes da atualização.

        Sempre que um mapa de aplicação personalizado é configurado com um ID de aplicação (appId) que já existe como parte de um mapa de aplicação inicial predefinido, o VMware SD-WAN Orchestrator mostrará sempre o nome a apresentar do mapa de aplicação inicial predefinido e substituirá o nome definido pelo cliente. Isto também é verdade quando o Orchestrator é atualizado de uma versão inferior para uma versão superior e o mapa da aplicação inicial predefinido da versão superior tem um appid que entra em conflito com o appId das aplicações personalizadas criadas numa versão inferior.  Após a atualização do Orchestrator, estas aplicações personalizadas mostrarão um nome de apresentação incorreto que é o nome de apresentação do appId do mapa de aplicação inicial predefinido da versão superior.

      • Problema 53752 resolvido: uma migração da empresa de cliente falha quando é tentada num VMware SD-WAN Orchestrator com a versão 3.4.x para um Orchestrator com a versão 4.2.0.

        A mais recente ferramenta de migração empresarial não suporta a versão 4.2.x e esta foi a causa das falhas de migração.

      • Problema 53767 resolvido: o cliente consegue ver os códigos HTML numa política empresarial quando os observa na IU do VMware SD-WAN Edge.

        As mensagens dinâmicas foram atribuídas a uma variável e a variável está anexada a uma cadeia, pelo que todo o valor da variável é apresentado como uma cadeia, incluindo as etiquetas HTML. A correção move o local onde a variável compõe o texto para uma nova etiqueta.

      • Problema 53798 resolvido: o cliente pode configurar um tipo ou valor de propriedade inválido para criar um handoff do Gateway de parceiro.

        O VMware SD-WAN Orchestrator não possui uma validação de sintaxe para a inserção ou atualização de um handoff de Gateway da empresa que é corrigida nesta versão.

      • Problema 53882 resolvido: o cliente pode editar as regras BFD num VMware SD-WAN Edge mesmo quando a sobreposição do Edge está desligada.

        O VMware SD-WAN Orchestrator tem um controlo de validação em falta para ver se a sobreposição do Edge está desligada ao tentar editar as regras BFD.

      • Problema 53857 resolvido: uma implementação do VMware SD-WAN Orchestrator que utiliza uma imagem KVM baseada na versão 4.0.0 não será implementada.

        O motivo para a falha é que a imagem KVM tem um tamanho de disco virtual incorreto e os volumes não vão ser expandidos para o tamanho necessário.  Numa implementação, os scripts do Orchestrator expandem automaticamente os volumes do Orchestrator para ocuparem 80% do espaço máximo dos discos subjacentes (volumes físicos).  Neste caso, devido ao tamanho virtual incorreto, esta expansão é inadequada para os requisitos da base de dados do Orchestrator e a implementação falha.  É possível implementar um Orchestrator com uma versão mais antiga sem esta correção, mas os volumes devem ser redimensionados manualmente.

      • Problema 53987 resolvido: num VMware SD-WAN Orchestrator, o Evento do Edge “Ligação MTU detetada” (Link MTU Detected) não é pesquisável na IU do Orchestrator.

        Este problema foi observado nos Orchestrators que utilizam a versão 4.0.x e superiores.  Ao realizar uma pesquisa de evento na IU do Orchestrator na página Eventos, a “Ligação MTU detetada” (Link MTU Detected) não está disponível na lista de Eventos para filtragem, dificultando assim o isolamento desse evento como parte do processo para resolução do problema.

      • Problema 54035 resolvido: se o modo de análise do VMware Edge Network Intelligence estiver ativado, os pacotes destinados ao syslog daemon, aruba daemon e snmptrap daemon serão ignorados no VMware SD-WAN Edge e os dados não serão apresentados no visualizador do Edge Network Intelligence.

        Os pacotes destinados aos daemons do Edge Network Intelligence (syslogd, amond e snmptrapd) são ignorados no processo de plano de dados do Edge devido a regras de iptable correspondentes em falta. Como resultado, as estatísticas correspondentes não são recebidas no back-end do Edge Network Intelligence.

      • Problema 54546 resolvido: a IU do VMware SD-WAN Orchestrator não apresenta corretamente os túneis do Serviço de Segurança na Cloud ou Não-SD-WAN via Edge na página Monitorizar > Edges (Monitor > Edges).

        O problema pode ocorrer quando existem vários VMware SD-WAN Edges que utilizam ligações WAN através de interfaces USB para CSS ou túneis NSD via Edge. O Orchestrator está a ordenar os eventos de túnel por hora e o evento mais recente por “datakey” está a ser utilizado para determinar o estado efetivo. Dado que o valor da chave é idêntico para muitas entradas, alguns dos túneis são excluídos. Este é apenas um problema de exibição sem impacto do cliente para além de mostrar um estado falso.

      • Problema 54861 resolvido: ao ativar o fornecedor automatizado Zscaler do Serviço de Segurança na Cloud (CSS) após mudar de um fornecedor IPsec manual, as credenciais antigas da VPN não são eliminadas das Definições do dispositivo do VMware SD-WAN Orchestrator, o que resulta na automatização não iniciar.

        O utilizador atribui um fornecedor IPsec de CSS manual ao VMware SD-WAN Edge e configura as suas credenciais de VPN. Em seguida, quando o utilizador muda para o fornecedor CSS automatizado, as credenciais antigas da VPN não são eliminadas pela IU. Isto leva a que a automatização não seja ativada. Sem a correção, a única forma de resolver o problema é eliminar manualmente todas as credenciais da VPN pré-existentes da IU do Orchestrator.

      • Problema 55205 resolvido: quando um utilizador paira sobre o gráfico QoE na página Monitorizar > QoE (Monitor > QoE) do VMware SD-WAN Orchestrator, a descrição lista os valores em atraso do pacote pela ordem errada.

        A ordem atual na qual os valores são apresentados é distorção e, em seguida, latência.  Mas a distorção é uma variação de atraso do pacote e deve ser corretamente listada após a latência, dado que a latência é uma expressão simples do atraso do pacote.

      • Problema 55259 resolvido: quando um administrador cria um novo VMware SD-WAN Edge na IU do VMware SD-WAN Orchestrator, o campo “Definir localização” (Set Location) está em falta.

        Com este problema, o administrador consegue criar o Edge mas sem as informações de localização, e o Orchestrator não consegue executar a geolocalização automática para o Edge e atribuir os Gateways corretos.  O administrador deve realizar um passo adicional após a criação do Edge para preencher as informações de localização do Edge na página Configurar > Edge > Visão geral do Edge (Configure > Edge > Edge Overview).

      • Problema 55294 resolvido: um utilizador apenas de teclado deve percorrer todas as ligações de navegação, sempre que navegar para uma nova página na IU do VMware SD-WAN Orchestrator.

        Falta em cada página uma ligação de conteúdo “Passar para o menu principal” (Skip to Main). Quando os utilizadores apenas de teclado interagem com a aplicação, eles utilizam a tecla de tabulação para passar de ligação em ligação. Os utilizadores devem avançar, utilizando a tecla de tabulação, através de todas as ligações de navegação sempre que chegam a uma nova página, simplesmente para alcançar o conteúdo principal.

      • Problema 55367 resolvido: na Nova IU do VMware SD-WAN Orchestrator, na página de Monitorizar > Aplicações (Monitor > Applications), existe um botão de impressão que não está etiquetado.

        Apesar de o botão de impressão estar visualmente em conformidade com o aspeto de um botão de impressão, não existe texto para comunicar explicitamente ao utilizador o que este botão faz ou como o utilizar.

      • Problema 55861 resolvido: um Destino Não-SD-WAN via Gateway com um tipo de Ponto de Verificação pode ter o tipo de NSD errado armazenado no VMware SD-WAN Orchestrator, o que levará a falhas de túnel.

        O tipo de túnel correto para um Ponto de Verificação NSD é “Outro” (Other).  No entanto, após uma atualização do Orchestrator, o tipo de NSD armazenado no Orchestrator pode ler o “Ponto de verificação” (Checkpoint) em comparação com “Outros” (Others) e, neste caso, “Ponto de Verificação” (Checkpoint) está realmente incorreto.  Dado que o Orchestrator está a enviar o tipo de NSD errado para o Gateway, os túneis podem não se formar.

      • Problema 55871 resolvido: algumas chamadas de API para REST APIv2 (/sdwan) HTTP fazem com que o servidor produza erros HTTP 500.

        Em alguns casos em que os dados dos clientes não estão exatamente em conformidade com o esquema que a API está à espera, a API produz um erro HTTP 500 em vez de devolver dados que são inconsistentes com o esquema documentado da API. Este comportamento foi impulsionado por uma decisão de design que entretanto foi reanalisada. Sabe-se que as chamadas para “GET /enterprises”, “GET /enterprises/{enterpriseLogicalId}/edges” e “GET /enterprises/{enterpriseLogicalId}/clientDevices” são afetadas.

      • Problema 56545 resolvido: os pacotes de reconhecimento negativo (NAK) DHCP não vão ser encaminhados para o cliente quando o VMware SD-WAN Edge está configurado como um agente de reencaminhamento DHCP e o servidor DHCP também está localizado no mesmo ramo.

        Sendo o Edge configurado como um agente de reencaminhamento DHCP e o servidor DHCP localizado no mesmo ramo, quando o endereço IP que não está no intervalo do servidor DHCP é solicitado, os pacotes DHCP NAK do servidor DHCP serão ignorados pelo Edge agindo como agente de reencaminhamento DHCP.

      • Problema 56763 resolvido: num VMware SD-WAN Orchestrator que utiliza a versão 4.x ou posterior com os relatórios ativados e, se por algum motivo o relatório não for gerado, todos os relatórios subsequentes de todos os clientes que utilizam o Orchestrator também não serão gerados até que o serviço back-end do Orchestrator seja reiniciado.

        Este problema tem um impacto significativo num Orchestrator afetado, dado que todos os clientes que utilizam o Orchestrator não vão conseguir obter relatórios até que o serviço de back-end do Orchestrator seja reiniciado. Este problema é provocado por uma única falha de relatório que coloca o serviço de relatórios num mau estado do qual não consegue recuperar sem reiniciar o serviço back-end no Orchestrator.  Isto ocorre porque a nova geração de relatórios não ocorre de forma independente da geração de relatórios anteriores.  A correção garante que o serviço de relatórios continua a gerar novos relatórios, independentemente de uma falha de geração de relatórios.

      • Problema 56824 resolvido: num VMware SD-WAN Orchestrator que utiliza a versão 4.2.x, a entrega de alertas aos destinatários do Webhook falha quando o URL do destinatário inclui um número de porta explícito.

        Os utilizadores que tinham anteriormente configurado URLs de destinatário do Webhook que incluíam números de porta explícitos podem observar que o alerta de entrega falha indefinidamente para esses destinatários. Sem a correção nesta versão, um administrador iria precisar de configurar um proxy inverso para passar pedidos para o destinatário original do Webhook e atualizar o URL do destinatário do Webhook para direcionar para o proxy inverso.

      • Problema 56896 resolvido: o utilizador pode sofrer falhas de API e tempos excedidos de Gateway.

        Este problema é o resultado de o armazenamento em disco do VMware SD-WAN Orchestrator estar cheio, devido à acumulação de ficheiros. Esta acumulação ocorre porque existe uma forma de desativar o processamento de estatísticas de fluxo para um VMware SD-WAN Edge ou uma lista de Edges que se assemelha à funcionalidade de lista de bloqueio/lista de negação. Embora o processamento de fluxo seja ignorado para estes Edges, o problema é que os ficheiros permanecem no disco do Orchestrator sem serem eliminados. Na instância encontrada em campo deste problema, existe monitorização suficiente em vigor para captar o problema e prevenir quaisquer problemas com a experiência do utilizador, mas no Orchestrator onde existe menos monitorização isto pode ter impacto sobre o tráfego do cliente. Sem esta correção, um operador Orchestrator teria de apagar manualmente os ficheiros no armazenamento de disco do Orchestrator com um carimbo de data/hora superior a 24 horas.

      • Problema 56909 resolvido: num VMware SD-WAN Orchestrator que utiliza a versão 4.x, a geração de relatórios pode falhar quando é incluída uma ligação de cópia de segurança.

        Se uma ligação não tiver registos estatísticos de ligação, a geração do relatório apresentará um erro.  Uma ligação definida para cópia de segurança não gerará estatísticas de ligação se permanecer estritamente como cópia de segurança durante o período selecionado para o relatório. Sem esta correção, a única forma de gerar um relatório é cancelar a seleção da ligação de cópia de segurança enquanto gera um relatório para que a ligação tenha alguns dados estatísticos para o seu registo.

      • Problema 57046 resolvido: na criação de um cliente no VMware SD-WAN Orchestrator, o acesso do operador é proibido. Mas quando o Orchestrator é atualizado para a versão 4.0.x, os privilégios MODIFY_ENTERPRISE_CUSTOM_ROLES e VIEW_PATH_STATS são adicionados por patches de sistema sem verificar o acesso do Operador.

        As definições do cliente mostram permissões delegadas ao Operador e, no entanto, o Operador não tem permissões para, por exemplo, ler serviços de rede ou modificar Edges/Perfis. Portanto, há um estado falso apresentado para o que um Operador pode fazer na empresa desse cliente.

      • Problema 57087 resolvido: quando o utilizador tentar mudar para o perfil VMware SD-WAN Edge no ecrã Configurar > Edge (Configure > Edge), o utilizador verá um erro de validação que inclui uma caixa de notificação com uma mensagem de erro genérica em vez do motivo real.

        O erro genérico indica “Erro ao processar o item. Tente novamente” (Error processing item. Please try again). Pelo motivo de erro de validação real, o utilizador teve de verificar a consola de depuração de um browser. Após a correção, é apresentado o erro de validação/motivo da falha apropriado.

      • Problema 57163 resolvido: o cliente não pode receber notificações via trap SNMP para os alertas do túnel do Serviço de Segurança na Cloud (CSS) ou do Destinos Não-SD-WAN (NSD) via Edge.

        O problema ocorre quando um cliente quer utilizar um trap SNMP para receber alertas de túneis CSS/NSD via Edge, mas os traps SNMP não estão a ser acionados para esses eventos.

      • Problema 57193 resolvido: ao configurar Relatórios no VMware SD-WAN Orchestrator, os utilizadores não conseguem agendar relatórios recorrentes ao utilizar a opção “Último ano” (Last Year).

        O Orchestrator apresenta um erro de validação quando isto é tentado. Esta é uma limitação da IU no tamanho da janela do browser.

      • Problema 58127 resolvido: O utilizador observará vários problemas com os Relatórios empresariais.

        Os problemas incluem um campo de ID nos relatórios que não deve ser apresentado, o nome de utilizador está em falta no relatório gerado e um limite de 50 relatórios.  Este pedido corrige os dois primeiros problemas.  O limite de 50 relatórios é uma configuração da Propriedade do sistema concebida para evitar problemas de desempenho do Orchestrator. Embora um administrador do Orchestrator pudesse aumentar o limite de relatórios, isso implicaria algum risco de desempenho no Orchestrator.

      • Problema 58288 resolvido: ao utilizar a Nova IU no VMware SD-WAN Orchestrator, um número incorreto de túneis por estado estão a ser apresentados em Monitorizar Edges > coluna “Túneis Edge” (Monitor Edges > “Edge tunnels”).

        Quando um utilizador abre a lista Monitorizar Edges (Monitor Edges), verá um número incorreto de túneis por estado, na coluna “Túneis Edge” (Edge tunnels).

      • Problema 58627 resolvido: os utilizadores configurados para receber alertas podem receber um alerta de Ligação ativa quando, na realidade, a ligação permanece inativa.

        Por vezes, após uma ligação ser assinalada como “Inativa” (Down), as estatísticas que foram geradas para essa ligação, antes da ligação ter ficado inativa, podem não ser enviadas para o VMware SD-WAN Orchestrator até um minuto após o evento.  Quando o Orchestrator recebe estas estatísticas de ligação com atraso, é levado a pensar que a ligação está novamente ativa e, portanto, aciona um alerta de Ligação ativa caso as definições dos alertas sejam “agressivas” (por exemplo, atraso de 0 minutos).  A correção garante que o Orchestrator não interpreta as estatísticas de ligação atrasadas como uma indicação de que a ligação está agora ativa.

      • Problema 58996 resolvido: a atualização dos campos BFD da IU do VMware SD-WAN Orchestrator lida com as validações e funciona sem qualquer problema. Mas o pedido da API correspondente não tem as validações. Além disso, o esquema JSON está em falta nos campos BFD.

        As informações de esquema JSON estão em falta no pedido da API, sendo estas utilizadas para gerar a documentação da API. Adicionalmente, o pedido da API não tem a validação do lado do servidor para os campos correspondentes que foram corretamente validados na IU.

      • Problema 59094 resolvido: quando um operador está a tentar atualizar um VMware SD-WAN Orchestrator, o script de atualização não fornece uma mensagem de aviso adequada sobre os requisitos de atualização do esquema.

        Se um operador falhar o passo de aplicação das alterações ao esquema nas tabelas maiores, poderá ocorrer um erro nos serviços do Orchestrator.  Também não existe uma forma fácil de descobrir que alterações estão em falta. Esta correção aborda este problema quando, ao reiniciar o serviço de back-end, este regenera alterações ao esquema em falta que são necessárias para uma tabela grande.

      • Problema 59689 resolvido: ao utilizar a Nova IU num VMware SD-WAN Orchestrator com um número excecionalmente elevado de empresas e Edges, a página Monitorizar > Registos de firewall (Monitor > Firewall Logs) pode carregar lentamente ou deixar de responder completamente.

        Este problema tem sido observado num Orchestrator alojado com mais de 200 empresas de cliente e milhares de Edges.

      • Problema 59967 resolvido: após um VMware SD-WAN Orchestrator ser atualizado para a versão 4.2.x ou superior, quando um utilizador Operador tenta aceder às páginas Configurar > Política empresarial (Configure > Business Policy) ou Configurar > Política de firewall (Configure > Firewall policy), a página não será carregada e o utilizador verá um erro.

        O erro indica “Ocorreu um erro inesperado” (An unexpected error has occurred). Isto afeta os utilizadores Operadores e não os Administradores de Clientes ou Parceiros. As páginas não carregam devido a uma LEITURA em falta: O privilégio OBJECT_GROUP para os Operadores, significando que o Orchestrator não reconhece um Operador como tendo os privilégios necessários para aceder às páginas de Política Empresarial e Firewall.

      • Problema 59987 resolvido: no e-mail de ativação Edge, a mensagem personalizada apresenta *****, em vez do texto real.

        A chave de mensagem anterior foi adicionada à lista de limpeza. E, é por isso, que ao enviar qualquer e-mail, como na ativação Edge, na reposição de palavra-passe (por exemplo, no texto de um e-mail, na criação de eventos, etc.), a chave da mensagem é obscurecida. Mas só para o e-mail de ativação é que a chave de mensagem tem de ser apresentada, dado que o campo é utilizado para enviar algumas informações personalizadas úteis ao utilizador.

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

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

      • Problema 60366 resolvido: um utilizador que utiliza a autenticação baseada em tokens não pode gerar um pacote de diagnóstico no VMware SD-WAN Orchestrator.

        Os utilizadores não seriam capazes de gerar Pacotes de Diagnóstico ao utilizarem a Autenticação Baseada em Token.

      • Problema 60405 resolvido: o campo de dados pathType está ausente no VMware SD-WAN Orchestrator que é atualizado para 4.3.x.

        Foi introduzido um novo campo “pathType” na tabela PathStats. O campo só foi observado num Orchestrator recém-implementado e não nos Orchestrators atualizados. A correção garante que o campo de dados “pathType” está presente tanto nos Orchestrators recém-implementados, como nos atualizados.

      • Problema 60444 resolvido: se um utilizador estiver a configurar um limite de taxa específico para um cliente/parceiro e, em seguida, desativar essa política utilizando o atributo “ativado: falso” (enabled:false), isto pode afetar os números de limite de taxa.

        O problema, neste caso de utilização em particular, surge quando um utilizador define uma política, mas depois a desativa na própria política.  Sem a correção, a solução alternativa para este problema é não adicionar as políticas na matriz de políticas de limite de taxa, caso seja suposto que as mesmas estejam desativadas. Basicamente, ignora todas as políticas que estão desativadas. Desta forma, apenas as políticas de limite de taxa existentes serão aplicáveis.

      • Problema 61000 resolvido: os perfis do operador recém-criados podem não ser selecionáveis na página Visão geral do parceiro (Partner Overview) na IU do VMware SD-WAN Orchestrator.

        Quando um Orchestrator tem mais de 100 perfis do operador e, em seguida, um utilizador tenta selecionar alguns deles na página Visão geral do parceiro (Partner Overview) apenas 100 serão apresentados na IU. Sem a correção, a única forma de resolver este problema é a Assistência Técnica do VMware SD-WAN atribuir o perfil de operador solicitado.

      • Problema 61312 resolvido: um VMware SD-WAN Orchestrator pode encontrar um problema quando os caminhos já não sejam atualizados e a utilização de CPU do Orchestrator esteja perto dos 100%, especialmente após o Orchestrator ser atualizado.

        Este problema manifesta-se quando um Edge envia mais de 2000 atualizações de caminho para a API de routing do Orchestrator. Nos cenários em que o Orchestrator não consegue processar todo o conjunto de caminhos enviados numa chamada de API específica em 60 segundos, resulta em tempo excedido para essa chamada, o que por sua vez resulta na rejeição total da chamada de API. O Edge recebe esta rejeição e tenta fazer push aos mesmos mais de 2000 caminhos novamente para o Orchestrator, levando ao mesmo cenário anterior, o que cria um ciclo que sobrecarrega os recursos da vCPU do Orchestrator. Quando este problema está presente, pode impedir que as atualizações de caminho sejam processadas. 

        Para resolver este problema, foram adicionadas duas propriedades do sistema:

        edge.learnedRoute.maxRoutePerCall Esta propriedade garante que apenas um número limitado de caminhos é processado num Edge. Se o valor da propriedade for “200”, serão processados 200 caminhos ppor pedido do Edge, o que garante que é enviado um reconhecimento atempadamente para o Edge.

        vco.learnedRoute.simultaneous.maxQueue Esta propriedade garante que apenas o número de Edges configurados pode ter pedidos de caminho em fila de espera de cada vez. Se o valor da propriedade for “8”, apenas será permitido a 8 Edges enviarem pedidos de caminho de cada vez e os que ultrapassarem o valor configurado serão rejeitados imediatamente antes de os caminhos serem processados.

      • Problema 61852 resolvido: a página Monitorizar > Registos de Firewall (Monitor > Firewall Logs) na nova IU não apresenta informações corretas de paginação.

        A contagem de linhas de página está incorreta para esta secção.

      • Problema 62038 resolvido: quando a visibilidade do cliente estiver definida para o modo MAC no VMware SD-WAN Orchestrator, a página Edge > Monitorização > Origens (Edge > Monitoring > Sources) nunca apresentará o mais recente IP para um determinado endereço MAC.

        Num determinado ramo, se um cliente alterar o seu endereço IP, o utilizador não conseguirá ver o endereço IP mais recente para esse cliente na página de Monitorização do Edge. Em vez disso, o utilizador verá um endereço IP obsoleto. Este problema é o resultado de uma lógica empresarial que consulta uma base de dados errada.

      Problemas conhecidos

      Problemas em aberto na versão 4.3.0

      Os problemas conhecidos são agrupados da seguinte forma.

      Problemas conhecidos do Edge/Gateway
      • Problema 14655:

        Ligar ou desligar um adaptador SFP pode fazer com que o dispositivo pare de responder no Edge 540, Edge 840 e Edge 1000 e exija um reinício físico.

        Solução alternativa: o Edge deve ser reiniciado fisicamente.  Este procedimento pode ser realizado no Orchestrator utilizando Ações Remotas > Reiniciar Edge (Remote Actions > Reboot Edge) ou através do ciclo de ativação do Edge.

      • Problema 25504:

        Custos do caminho estático superiores a 255 podem resultar numa ordenação de caminho imprevisível.  

        Solução alternativa: utilize um custo de caminho entre 0 e 255

      • Problema 25595:

        Poderá ser necessário um reinício para que as alterações ao SLA estático num overlay WAN funcionem corretamente.  

        Solução alternativa: Reinicie o Edge após adicionar e remover o SLA estático do overlay WAN

      • Problema 25742:

        O tráfego contabilizado de underlay está limitado à capacidade máxima do VMware SD-WAN Gateway, mesmo que seja inferior à capacidade da ligação WAN privada que não está ligada ao Gateway.  

      • Problema 25758:

        As ligações WAN USB podem não ser corretamente atualizadas quando são trocadas de uma porta USB para outra, até que o VMware SD-WAN Edge seja reiniciado.  

        Solução alternativa: reinicie o Edge após mover as ligações WAN USB de uma porta para outra.

      • Problema 25855:

        Uma grande atualização de configuração no Gateway de parceiro (por exemplo, 200 VRFs 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 local do ramo também deve ser atribuído a um cluster do VMware SD-WAN Hub para túneis ao cluster a ser estabelecido.  

      • Problema 28175:

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

      • Problema 31210:

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

      • Problema 32731:

        Os caminhos predefinidos condicionais anunciados através de OSPF 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 34254:

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

      • Problema 35778:

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

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

      • Problema 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 39659:

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

      • Problema 39753:

        A desativação da VPN Ramo-a-Ramo Dinâmica pode fazer com que os fluxos existentes que estão atualmente a ser enviados 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 42278:

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

      • Problema 42388:

        Num VMware SD-WAN Edge 540, uma porta SFP não é detetada após desativar e ativar novamente a interface no VMware SD-WAN Orchestrator.

      • Problema 42488:

        Num VMware SD-WAN Edge em que o VRRP está ativado para uma porta comutada ou encaminhada, se o cabo estiver desligado da porta e o Serviço do Edge for reiniciado, os caminhos ligados da LAN serão anunciados.

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

      • 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: para uma 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 44995:

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

      • Problema 45189:

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

      • Problema 45302:

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

      • Problema 46053:

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

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

      • Problema 46137:

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

      • Problema 46216:

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

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

      • Problema 46391:

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

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

      • Problema 46918:

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

      • Problema 47084:

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

      • Problema 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 47681:

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

      • Problema 47787:

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

      • Problema 48166:

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

      • Problema 48175:

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

      • Problema 48502:

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

      • Problema 48530:

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

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

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

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

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

      • Problema 48666:

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

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

      • Problema 49172:

        Uma regra NAT Baseada em Política configurada com a mesma sub-rede NAT para dois VMware SD-WAN Edges não funciona.

      • 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 interfaces operacionais de 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 local 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 local 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: após um reequilíbrio do cluster do VMware SD-WAN Hub, alguns Spoke Edges podem não ter a interface RPF/IIF com a definição correta.

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

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

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

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

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

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

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

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

      • Problema 53687: quando um Spoke Edge 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 vai 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 realizando uma opção de “Atualização” (Refresh) na página OFC do VMware SD-WAN Orchestrator para os caminhos afetados. Tenha em atenção que ao realizar a “Atualização” (Refresh) de um caminho vai reaprender os caminhos de todos os Edges na empresa.

      • Problema 53934: numa empresa onde está configurado um cluster do VMware SD-WAN Hub, se o Hub principal tiver 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 54846: 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.

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

      • Problema 56218: para um local de 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 vai ser definido para HA_FAILED no VMware SD-WAN Orchestrator.

        Solução alternativa: reinicie o Edge em espera para o recuperar

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

      • Problema 58453: 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 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 62552: um local pode experimentar 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: tanto o problema 60130 como este problema têm o mesmo comportamento e causa subjacentes, mas as correções esperadas para cada pedido diferem. O 60130 terá uma correção de solução alternativa defensiva, enquanto o 62552 terá uma correção completa que impede qualquer recorrência deste problema.

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

      • 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 62725: um VMware SD-WAN Edge numa rede que utiliza 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 Spoke Edge, a MTU aumentada será refletida na MTU de caminho no Spoke.

      • Problema 63362: num local que utiliza uma topologia de Alta Disponibilidade melhorada, uma interface ativada por DHCP/PPPoE para de enviar tráfego após o VMware SD-WAN Edge em espera ser reiniciado ou passar o ciclo de ativação.

        Numa configuração de HA melhorada, se o DHCP/PPPoE estiver ativado numa interface de proxy (isto é, o estado de ligação de HA definido como USE_PEER), o endereço do servidor não será após o Edge em espera ser reiniciado ou ocorrer o ciclo de energia.

        Solução alternativa: altere o endereço dinâmico para um tipo de endereço estático ou faça uma recuperação automática de HA forçada para obter o endereço IP do servidor.

      • 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 84825: Para um site implementado com uma topologia de alta disponibilidade onde o BGP está configurado, se o site tiver configuradas mais de 512 regras BGPv4 de correspondência e definição, o cliente poderá observar o par Edge HA a falhar continuamente sem nunca recuperar.

        Mais de 512 regras de 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.

      Problemas conhecidos do Orchestrator
      • Problema 19566:

        Após a recuperação automática da Alta Disponibilidade, o número de série do VMware SD-WAN Edge em espera pode ser apresentado como o número de série ativo no Orchestrator.

      • Problema 21342:

        Ao atribuir Gateways de parceiro por segmento, a lista correta de Atribuições de Gateway pode não aparecer na opção “Ver” (View) Gateways do Operador na lista de monitorização do VMware SD-WAN Edge.

      • Problema 24269:

        Monitorizar > Transportar > A perda não representada em gráficos (Monitor > Transport > Loss not graphing) observou uma perda da ligação WAN enquanto os gráficos QoE refletiram esta perda. 

      • Problema 25932:

        O VMware SD-WAN Orchestrator permite que os VMware SD-WAN Gateways sejam removidos do Conjunto de Gateways mesmo quando estão a ser utilizados.

      • Problema 32335:

        A página “Acordo de Serviços do Utilizador Final” (EUSA) (End User Service Agreement (EUSA)) apresenta um erro quando um utilizador está a tentar aceitar o acordo.

        Solução alternativa: certifique-se de que não existem espaços iniciais ou finais no nome da empresa.

      • Problema 32435:

        É permitida uma sobreposição de VMware SD-WAN Edge para uma configuração NAT baseada em políticas para cadeias de identificação que já estão configuradas ao nível do perfil e vice-versa.

      • Problema 32856:

        Embora a política empresarial esteja configurada para utilizar um cluster de Hub para realizar o backhaul do tráfego de Internet, o utilizador pode desmarcar o cluster de Hub de um perfil num VMware SD-WAN Orchestrator que foi atualizado da versão 3.2.1 para a versão 3.3.x.

      • Problema 32913:

        Após ativar a Alta Disponibilidade, os detalhes de Multicast 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 34828:

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

      • Problema 35658:

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

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

      • Problema 35667:

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

        Solução alternativa: 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 de Edge não mostra os dados da região.

      • Problema 38843:

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

      • Problema 39633:

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

      • Problema 39790:

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

      • Problema 40341:

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

      • Problema 41691:

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

      • Problema 43276:

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

      • Problema 47269:

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

      • Problema 47713:

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

      • Problema 47820:

        Se uma VLAN estiver configurada com o DHCP desativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existe uma entrada para o campo de servidor DNS definido 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 48737:

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

      • Problema 49225:

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

      • Problema 49790:

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

        Solução alternativa: ignore o evento duplicado.

      • Problema 50531:

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

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

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

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

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

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

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