Atualizado a 25 de outubro de 2021

VMware SD-WAN™ Edge versão R440-20210701-GA-61583

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 necessitem das funcionalidades e características disponibilizadas pela primeira vez na Versão 4.4.0.

Compatibilidade

A utilização do VMware SASE requer a versão 4.4.0 ou superior em todos os componentes.


Nota: a versão 4.4.0 só pode ser utilizada em implementações novas. Os clientes com implementações de redes existentes que utilizam a versão 4.3.x ou anterior não podem atualizar para esta versão.

Notas importantes

VMware SASE™

A começar com a versão 4.4.0, o VMware oferece uma plataforma abrangente de Secure Access Service Edge (SASE) através da cloud que reúne soluções líderes do setor da VMware. Como parte desta transformação, estamos a alterar o nome de versão do VMware SD-WAN para versão do VMware SASE para refletir o conjunto mais amplo de serviços SASE proporcionados pela nossa solução.

O VMware Secure Access Service Edge (SASE) é uma solução alojada na cloud que permite a qualquer utilizador em qualquer dispositivo e em qualquer local um acesso fiável, eficiente e ideal a qualquer aplicação na cloud com imposição de segurança. Como solução extensível, o VMware SASE fornece serviços de rede e segurança através de uma rede global de VMware SASE PoPs (Pontos de Presença). O VMware SASE utiliza um único painel de gestão para configurar, gerir e monitorizar estes serviços. A solução disponibiliza informações acionáveis sobre a experiência operacional do utilizador final e do dispositivo IoT.

A solução está disponível como um serviço gerido ou “Faça você mesmo” e tira partido de uma rede global de nós de serviços em cloud.    

O VMware SASE é composto por quatro soluções: 

  • O VMware SD-WAN™ é a WAN definida por software líder no setor, que oferece um acesso de ramo fiável e de alto desempenho para uma implementação fácil, bem como uma gestão em ambientes de cloud ou híbridos.

  • O VMware Cloud Web Security™ é um serviço alojado na cloud que protege os utilizadores e as infraestruturas que acedem a aplicações SaaS e da Internet contra ameaças, oferecendo visibilidade, controlo e conformidade. 

  • O VMware Secure Access™ é uma solução de acesso remoto que se baseia numa estrutura Zero Trust Network Access (ZTNA). A solução alojada na cloud oferece vários benefícios em comparação com as soluções tradicionais de VPN, permitindo aos utilizadores um acesso consistente, ideal e seguro às aplicações na cloud. 

  • O VMware Edge Network Intelligence™ é uma solução AIOps agnóstica de fornecedor focada no Edge empresarial que assegura a garantia operacional do cliente IoT e do utilizador final à medida que o tráfego destes dispositivos percorre a LAN, o SD-WAN e o SASE sem e com fios.

Notas sobre a implementação

  • Os VMware SASE PoPs (Pontos de Presença) estão a ser implementados com a versão 4.4.0. Para quaisquer questões relacionadas com o PoP mais próximo, contacte o representante de vendas VMware. 
  • Os parceiros que planeiam migrar os clientes SD-WAN existentes para tirar partido dos serviços do VMware SASE devem contactar o respetivo representante de vendas VMware.

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 implementarem uma rede com a versão 4.4.0, cuja única experiência anterior tenha sido com a versão 3.x, necessitam de garantir que as configurações de AS-PATH precedente utilizam apenas espaços como delimitadores, de forma a evitar uma seleção incorreta da melhor rota do BGP.

Novas funcionalidades

VMware Cloud Web Security

O VMware Cloud Web Security é um serviço alojado na cloud que protege os utilizadores e as infraestruturas que acedem a aplicações SaaS e da Internet contra um panorama em mudança de ameaças internas e externas, oferece visibilidade e controlo e garante a conformidade. 

O Cloud Web Security é disponibilizado através de uma rede global de PoPs (Pontos de presença) do VMware SASE para garantir que os utilizadores localizados em qualquer lugar e que se ligam em qualquer dispositivo têm um acesso às aplicações seguro, consistente e ideal. O Cloud Web Security simplifica a gestão dos serviços de segurança e ajuda as equipas de TI a reforçar a política de segurança sem prejudicar a produtividade dos utilizadores.   

O Cloud Web Security proporciona às equipas de TI a visibilidade e o controlo de que necessitam para manter uma forte política de segurança, ao mesmo tempo que respeitam as necessidades de conformidade com as seguintes vantagens:   

  • Política de segurança ágil. Uma vez que é um serviço alojado na cloud, qualquer ameaça detetada em qualquer lugar pelo Cloud Web Security é imediatamente bloqueada para todos os clientes que tiram partido das propriedades nativas da cloud.  
  • Acesso seguro contínuo para a força de trabalho em qualquer lugar. Aproveitando uma rede global de PoPs do VMware SASE, o Cloud Web Security oferece acesso seguro e ideal aos utilizadores para aplicações da Internet e SaaS.  
  • Operações simplificadas. O Cloud Web Security utiliza um painel de gestão centralizado que tira partido do VMware SD-WAN Orchestrator para serviços de rede e serviços de segurança que simplificam a implementação e as operações de um local de trabalho distribuído.  
  • Redução do custo operacional. O Cloud Web Security oferece poupanças ao nível da gestão do ciclo de vida e do ciclo de atualização de aparelhos físicos ou virtuais implementados no local.  

O que é oferecido na versão 4.4.0

O VMware Cloud Web Security permite que os administradores de TI reduzam a superfície de ataque com filtragem de URL e filtragem de conteúdo. A filtragem de URL ajuda a controlar os sites a que os funcionários podem aceder. A filtragem de conteúdo ajuda a limitar o tipo de conteúdo a que os utilizadores podem aceder. O conteúdo é inspecionado para detetar ataques de malware de vírus conhecidos utilizando informações sobre ameaças atualizadas. A solução protege contra malware de dia zero com suporte de sandbox onde o conteúdo é inspecionado num ambiente contido. O Cloud Web Security inclui suporte para proxy SSL com desencriptação para inspecionar a grande maioria das aplicações Web que são encriptadas por SSL hoje em dia. A solução também oferece visualização avançada de tráfego e ameaças através de painéis de segurança e registos Web.

O VMware Cloud Web Security estará disponível para os clientes em 2 Edições:  

1. Edição Standard 
2. Edição Avançada 

A versão 4.4.0 será lançada com o pacote Cloud Web Security Edição Standard. Além disso, iremos ativar a funcionalidade Sandbox avançado (Advanced Sandbox) no lançamento da versão. Embora a funcionalidade Sandbox avançado (Advanced Sandbox) faça parte do pacote Cloud Web Security Edição Avançada, os clientes poderão pré-visualizar as capacidades durante um período limitado até lançarmos o Cloud Web Security Edição Avançada.  

Segue-se um resumo das funcionalidades do Cloud Web Security que estarão disponíveis nas Edições Standard e Avançada. As células realçadas são as funcionalidades que estarão disponíveis na disponibilidade geral da versão 4.4.0. 

Edição

Padrão

Avançado

Filtragem de URL

             X            

X

Inspeção SSL

             X            

X

Filtragem de conteúdo

             X            

X

Verificação de hash de ficheiro

             X            

X

Antivírus

             X            

X

Autenticação

             X            

X

Sandbox básico

             X            

X

Sandbox avançado*

             X            

X

Registo SIEM**

             X            

X

CASB inline

Visibilidade

Visibilidade e controlo

DLP inline

 

X

Integração do Microsoft MCAS

X

X

* Parte do pacote Cloud Web Security Edição Avançada disponível para pré-visualização inicial. 

** O Registo SIEM foi inicialmente indicado como uma funcionalidade disponível. No entanto, a API necessária para implementar o Registo SIEM continua em desenvolvimento, pelo que esta funcionalidade está efetivamente indisponível na versão 4.4.0. A implementação da API necessária para o Registo SIEM estará disponível numa versão futura.

O Sandbox básico e o Sandbox avançado diferem no tipo de conteúdo que pode ser inspecionado.  A tabela seguinte lista as diferenças entre as funcionalidades do Sandbox básico e Sandbox avançado: 

 

 

Sandbox básico

Sandbox avançado

Tipos de documentos

Aplicações de engenharia

 

X

Aplicações de produtividade

 

X

Processadores de texto

 

X

Folhas de cálculo

 

X

Ferramentas de apresentação

 

X

Tipos de ficheiros

Scripts e executáveis

X

X

Arquivos e pacotes comprimidos

X

X

Multimédia

 

X

Calendário

 

X

VMware Secure Access

A solução VMware Secure Access proporciona aos utilizadores remotos e móveis um acesso consistente, ideal e seguro às aplicações na cloud através de uma rede de nós de serviço geridos a nível mundial. A solução baseia-se na arquitetura Zero Trust Network Access (ZTNA) que oferece vários benefícios em relação à solução tradicional de VPN:

  • O VMware Secure Access está alojado na cloud, permitindo que as empresas se libertem da dispendiosa implementação, manutenção e escala da solução de acesso remoto para uma melhor eficiência de TI.
  • O VMware Secure Access oferece acesso centrado no utilizador e na aplicação versus acesso baseado na rede com uma VPN. O acesso é concedido com base na identidade do utilizador e na política do dispositivo final, com acesso apenas às aplicações de que o utilizador necessita, reduzindo significativamente a superfície de ataque.
  • Independente da localização significa que oferece uma política de acesso consistente, independentemente do local de acesso do utilizador.

A solução aproveita a pegada global de PoPs (Pontos de presença) do VMware e otimiza as capacidades de processamento de tráfego para uma menor latência e melhor desempenho das aplicações, permitindo que os clientes proporcionem uma experiência de ramo aos funcionários remotos.

O que é oferecido na versão 4.4.0

A versão 4.4.0 do VMware SASE também permite que os utilizadores remotos se liguem às aplicações através do VMware Secure Access utilizando dispositivos geridos por terceiros ou BYOD, além de dispositivos geridos pelo VMware Workspace ONE disponíveis anteriormente. Nesta versão, o limite mínimo de 700 utilizadores e o limite de 5 GB de dados foram levantados e os clientes podem agora aprovisionar o Secure Access de forma autónoma sem suporte da VMware.

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

Os consumidores da API do Portal (“APIv1”) podem encontrar um registo de alterações abrangente disponível para transferência em code.vmware.com.

A versão 4.4.0 não afeta a APIv2 SD-WAN.

Esta versão apresenta duas novas APIs do Orchestrator: a API REST do Cloud Web Security e a API REST do Secure Access. Esperamos publicar documentação para estas APIs em developer.vmware.com assim que forem declaradas estáveis para utilização por clientes e parceiros.

Uma vez publicadas ambas as APIs, as Notas de Versão serão revistas e republicadas com hiperligações para essa documentação.  Verifique periodicamente se existem atualizações nesta secção.

Histórico de revisões do documento

10 de junho de 2021. Primeira edição

22 de junho de 2021. Segunda edição

  • Foi adicionada uma nova versão de lançamento do Edge, R440-20210617-GA, à secção Problemas resolvidos e adicionado um problema corrigido associado a essa versão n.º 59509.

2 de julho de 2021, terceira edição

  • Foi adicionada uma nova compilação GA R440-20210701-GA-61583 do Edge à secção Resolvido. Este Edge aborda o novo problema 61583 resolvido.

27 de agosto de 2021, quarta edição

  • Foi adicionada uma formulação clara de que a versão 4.4.0 se destina apenas a implementações de raiz, o que significa que o cliente não pode atualizar para a versão 4.4.0 a partir de uma versão mais antiga. Tem de implementar como uma nova empresa a utilizar a versão 4.4.0.

16 de setembro, quinta edição

  • A tabela de disponibilidade de funcionalidades do Cloud Web Security foi revista para indicar que o Registo SIEM não está disponível na versão 4.4.0. O Registo SIEM foi inicialmente indicado como uma funcionalidade disponível. No entanto, a API necessária para implementar o Registo SIEM continua em desenvolvimento, pelo que esta funcionalidade está efetivamente indisponível na versão 4.4.0.
  • Foi adicionada às Notas importantes a seguinte nota: Alteração ao delimitador da configuração de filtro BGPv4 para o AS-PATH precedente.

25 de outubro, sexta ediçã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.

Problemas resolvidos

Os problemas resolvidos são agrupados da seguinte forma.

Problema resolvido do Edge

Resolvido na versão R440-20210702-GA-61583

O problema abaixo foi resolvido a partir da versão R440-20210617-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)

Problema resolvido do Edge

Resolvido na versão R440-20210617-GA do Edge

O problema abaixo foi resolvido desde a versão R440-20210610-GA do Edge

  • Problema 59509 resolvido: o VMware SD-WAN Edge não interpreta corretamente a Licença Edge atribuída a esse Edge.

    Ao ligar a um SASE PoP, o Edge pode estar a utilizar funcionalidades inconsistentes com o tipo de licença atribuído ao Edge.

Problemas resolvidos do SD-WAN Edge/Gateway

Resolvido na versão R440-20210610-GA do Edge. Não existem versões de Gateway.

Não existem novos problemas resolvidos desde a versão do Edge R430-20210528-GA e a versão do Gateway R430-20210605-GA.

    Problemas resolvidos do Orchestrator

    Não existem novos problemas resolvidos desde a versão do Orchestrator R430-20210527-GA.

      Problemas conhecidos

      Problemas em aberto na versão 4.4.0

      Os problemas conhecidos são agrupados da seguinte forma.

      Problemas conhecidos do SD-WAN 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 configurados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.

        Solução alternativa: nenhuma solução alternativa disponível.

      • Problema 25921:

        A recuperação automática do VMware SD-WAN Hub de Alta Disponibilidade demora mais do que o esperado (até 15 segundos) quando existem três mil Edges de ramo ligados ao Hub.  

      • 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 configurada 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 do DPDK será completamente desativada se a interface for primeiro 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 configurada por DPDK pode não gerar corretamente eventos de “Novo dispositivo de cliente” para todos os clientes ligados.

      • Problema 38767:

        Quando um overlay WAN que tenha túneis GRE configurados para o Zscaler é alterado da deteção automática para definido pelo utilizador, os túneis obsoletos podem permanecer até ao próximo reinício.

        Solução alternativa: reinicie o Edge para limpar o túnel obsoleto.

      • Problema 39134:

        A estatística de estado de funcionamento do Sistema “Percentagem de CPU” (CPU Percentage) pode não ser comunicada corretamente em Monitorizar > Edge > Sistema (Monitor > Edge > System) para o VMware SD-WAN Edge e em Monitorizar > Gateways (Monitor > Gateways) para o VMware SD-WAN Gateway.

        Solução alternativa: os utilizadores devem utilizar as Handoff Queue Drops para monitorizar a capacidade do Edge e não a percentagem de CPU.

      • Problema 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 que tem uma porta comutada com VRRP ativado, se o cabo estiver desligado 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 49738:

        Em certos casos, quando o Spoke Edge do VMware SD-WAN é configurado para utilizar vários Edges Hub, o Spoke Edge não consegue formar túneis para um dos Hubs configurados na lista de Hubs.

      • 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 configuradas por DPDK. Atualmente, a única forma de obter os valores de velocidade para as portas configuradas 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 configuradas 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á definido como 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á configurada 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 existir uma falha do lado LAN ou quando o BGP for 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 configurada 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 56218: para um local de cliente implementado com uma topologia de Alta Disponibilidade ou onde a HA acaba de ser configurada, quando os Edges são atualizados de 3.2.x para 3.4.x, o Edge em espera poderá ficar inativo.

        Quando a HA (alta disponibilidade) está configurada ou os Edges HA são atualizados de 3.2.2 para 3.4.x após a configuração de uma definição WAN com a IU local, a interface HA (por exemplo, LAN1 ou GE1 dependendo do modelo Edge) será removida do Edge em espera e o estado HA será definido como 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 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 configurada 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 configurado numa interface de proxy (isto é, o estado de ligação de HA definido como USE_PEER), o endereço do servidor não será obtido 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 64736: os IPs do DHCPv6 podem não ser removidos de uma interface VMware SD-WAN Edge depois de configurar a interface de encaminhada para comutada.

        Quando uma interface é convertida de encaminhada para comutada, os endereços IP IPv6 devem ser removidos da interface porque o IPv6 não é suportado na LAN. Contudo, em alguns casos, os endereços IP IPv6 não são removidos após a conversão para comutado. Estes endereços IP persistem mesmo se a interface for devolvida. O problema não ocorre sempre que uma interface é convertida.

        Solução alternativa: reinicie o Edge para limpar os endereços IP IPv6 da interface comutada recentemente convertida.

      • Problema 64909: O caminho do centro de dados para um Destino Não-SD-WAN via Gateway é definido como falso ao alterar o endereço IP do Gateway.

        Quando o endereço IP é alterado para o Gateway principal de um NSD, o túnel aparece, mas se os caminhos forem verificados no Gateway, o caminho para o centro de dados/par está definido como Falso.

        Solução alternativa: se o serviço do Gateway for reiniciado, o caminho do centro de dados aparece, o que é algo que deve acontecer numa janela.

      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 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 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 44153:

        O VMware SD-WAN Orchestrator não envia consistentemente e-mails de alerta para os endereços de e-mail configurados na secção “Alertas e notificações” (Alerts and Notifications).

      • 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 definida como desativada, a configuração NAT deverá ser reconfigurada ao ativar a VPN de cloud.

      • Problema 47820:

        Se uma VLAN estiver configurada com o DHCP definido como desativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existe uma entrada para o campo de servidor DNS definido como nenhum (nenhum IP configurado), o utilizador não poderá fazer qualquer alteração na página Configurar > Edge > Dispositivo (Configure > Edge > Device) e receberá uma mensagem de erro de “endereço IP inválido []” (invalid IP address []) que não explica nem indica o verdadeiro problema.

      • Problema 48085:

        O VMware SD-WAN Orchestrator permite que um utilizador elimine uma VLAN que esteja associada a uma interface.

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

      • Problema 63726: num site que tem configurado um Destino Não-SD-WAN (NSD) via Gateway utilizando um tipo Zscaler e o atribuiu ao segmento global, se um utilizador alterar o NSD Zscaler atribuído do global para um segmento não global, o caminho 0.0.0.0/0 para o par está em falta nos VMware Edges.

        No VMware Gateway o caminho está presente, mas no Edge o caminho esperado do centro de dados não está presente. O Orchestrator não está a atribuir o caminho a Edges no segmento não global recentemente atribuído.

        Solução alternativa: remova a configuração do centro de dados do segmento principal e guarde a configuração. Espere que o túnel seja completamente destruído ao verificar os eventos.  Atribua uma nova configuração do centro de dados ao novo segmento não global e guarde a configuração.  Serão atribuídos novos caminhos ao novo segmento não global.

      • Problema 64716: 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).

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

      • Problema 64847: numa IU do VMware SD-WAN Orchestrator onde a região do browser está definida para um idioma que não o inglês, quando se utiliza a nova IU, faltam todas as opções no painel Menu de nível superior (Top Level Menu).

        Na nova IU, existe um ícone de “três linhas” no canto superior direito do ecrã e se, um utilizador clicar no ícone de “três linhas”, deverá acionar a abertura de um painel de “Menu de nível superior” (Top Level Menu). Por vezes, estes ícones não navegam para o destino pretendido.

        Solução alternativa: recarregue a página para forçar a apresentação da página pretendida.

      Problemas do Cloud Web Security
      • Problema 62934: para uma empresa que utiliza o VMware Cloud Web Security, se um utilizador cliente abrir um browser Chrome no modo de navegação anónima e tentar transferir um ficheiro, a transferência pode, ocasionalmente, não ser bem-sucedida.

        O modo de navegação anónima requer a ativação de cookies de terceiros. Ative os cookies de terceiros e volte a tentar a operação. Numa transferência sem êxito, o utilizador observaria um ecrã onde se lê “Ocorreu um erro. Contacte o administrador” (Error occurred contact your administrator) ou, para ficheiros de um servidor Web personalizado: “Esta página não está a funcionar” (This page is not working). Ocasionalmente, alguns servidores Web ou ficheiros podem ter uma variação na assinatura de ficheiro, que o Cloud Web Security Service pode não ser capaz de reconhecer, resultando neste problema.

        Solução alternativa: autorize os cookies de terceiros e tente novamente. Não há uma solução conhecida para este problema se utilizar uma janela de navegação anónima.

      • Problema 62978: para uma empresa que utiliza o VMware Cloud Web Security, se um utilizador cliente abrir um browser Chrome no modo de navegação anónima e tentar transferir um ficheiro, a transferência pode falhar e, caso isso aconteça, o utilizador poderá ver um ecrã de erro que não tem a marca VMware.

        No cenário acima em que uma transferência de ficheiros falha (que é abordado no problema n.º 62934), o ecrã de erro “Ocorreu um erro. Contacte o administrador” (Error occurred contact your administrator) deveria mostrar a marca VMware, mas, em vez disso, não mostra nenhuma marca. Se um utilizador se deparar com este erro, deverá perceber que este não é um resultado esperado.

        Solução alternativa: permita os cookies de terceiros no browser.

      • Problema 63149: quando uma implementação do cliente tem sub-redes sobrepostas num perfil e configura uma sub-rede para uma política do VMware Cloud Web Security e associa a política do Cloud Web Security ao perfil e segmento, os clientes Edge nessa sub-rede não serão capazes de se ligar à Internet.
        Caso o tráfego falhe, os clientes não poderão aceder à Internet.

        Se houver sub-redes sobrepostas configuradas para os segmentos LAN por trás dos VMware SD-WAN Edges dentro do mesmo segmento, os recursos por trás dos Edges não podem ter políticas do Cloud Web Security aplicadas para o tráfego ligado à Internet. Isto porque não há forma de identificar exclusivamente o Edge de destino para o tráfego de retorno da Internet para o Cloud Web Security.

        Solução alternativa: ative o NAT do lado LAN no Edge e tenha uma sub-rede única que represente o tráfego originado a partir de recursos por trás do Edge.

      • Problema 64429: numa empresa de clientes que utiliza o VMware Cloud Web Security, onde uma política do Cloud Web Security está configurada e é aplicada através do backhaul de Internet, uma transferência UDP para um servidor na Internet, iniciada por um cliente por trás do Edge, com um bit DF definido, irá falhar.

        O Cloud Web Security receberá pacotes de tamanho MTU, mas terá de enviar uma mensagem inalcançável ICMP de volta ao remetente, uma vez que a fragmentação não é permitida devido ao bit Não fragmentar (DF) definido. O Cloud Web Security está a executar o DNAT (tradução de endereços de rede de destino) para o endereço IP de origem errado e está a enviar uma mensagem “ICMP inalcançável, fragmentação necessária” (ICMP unreachable fragmentation needed) ao cliente, em vez de a enviar de volta para o servidor.

        Solução alternativa: espera-se que o TCP funcione ou utilize UDP sem o bit DF definido.

      • Problema 65001: para um cliente que utiliza o VMware Cloud Web Security, um utilizador não pode configurar o Motor de inspeção para ativar/desativar as Verificações de hash de ficheiro através do VMware Orchestrator.

        Quando um utilizador está a utilizar o Orchestrator para configurar o parâmetro de Verificação de hash de ficheiro do Motor de inspeção do Cloud Web Security para “Ação para transferência de ficheiro desconhecido” (Action for Unknown File Download) e “Ação para transferência de documento desconhecido” (Action for unknown document Download), estas alterações não são enviadas para o Motor de inspeção e não são aplicadas.

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

      • Problema 65115: para um cliente que utilize o VMware Cloud Web Security, se a autenticação SAML estiver configurada, o utilizador poderá não ter acesso a nenhum site.

        Com a autenticação SAML (Security Assertion Markup Language) ativada, se um utilizador aceder a qualquer site, tal resultará num ciclo de autenticação onde o acesso ao IdP (Fornecedor de identificação) requer autenticação e falha.

        Solução alternativa: adicione uma Exceção SSL na política de segurança para permitir o acesso ao URL de início de sessão do IdP sem autenticação.

      Problemas do Secure Access
      • Problema 64541: para um cliente que utiliza o VMware Secure Access, ao utilizar a opção na configuração do Workspace ONE UEM para configurar o nome de anfitrião do túnel dentro do Grupo da organização, se um utilizador selecionar “Sim” (Yes), o nome de anfitrião será criado automaticamente na consola UEM em vez de ser configurado manualmente.

        O utilizador deve ter a opção de configurar manualmente o nome de anfitrião e não apenas criá-lo automaticamente.  

        Solução alternativa: a solução é defini-lo manualmente na consola UEM.

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