Notas de versão 5.4.0 do VMware SASE

VMware SASE 5.4.0 | 16 de novembro de 2023 VMware SASE™ Orchestrator versão R5401-20231115-GA VMware SD-WAN™ Gateway versão R5400-20231009-GA VMware SD-WAN™ Edge versão R5400-20231108-GA-125647 Verifique 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
• Compatibilidade
• Caminhos de atualização do Orchestrator, Gateway e Edge
• Novas funcionalidades e melhorias do SASE
• Novas funcionalidades e melhorias do SD-WAN
• Notas importantes
• Idiomas disponíveis
• Alterações à API do Orchestrator
• Histórico de revisões do documento

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

A versão 5.4.0 contém todas as correções do Edge e Gateway indicadas nas Notas de versão 5.2.0 até à versão 5.2.0.2 e todas as correções do Orchestrator indicada nas Notas de versão 5.2.0 até à versão 5.2.0.3 e nas Notas de versão 5.3.0 até à versão 5.3.0.2.

Compatibilidade

A versão 5.4.0 dos Orchestrators, Gateways e Edges Hub suporta todas as versões anteriores do VMware SD-WAN Edge iguais ou superiores à versão 4.2.0.

Foram explicitamente testadas as seguintes combinações de interoperabilidade do SD-WAN:

Orchestrator	Gateway	Edge
		Hub	Ramo/Spoke
5.4.0	4.2.2	4.2.2	4.2.2
5.4.0	5.4.0	4.2.2	4.2.2
5.4.0	5.4.0	5.4.0	4.2.2
5.4.0	5.4.0	4.2.2	5.4.0
5.4.0	4.3.2	4.3.2	4.3.2
5.4.0	5.4.0	4.3.2	4.3.2
5.4.0	5.4.0	5.4.0	4.3.2
5.4.0	5.4.0	4.3.2	5.4.0
5.4.0	4.5.2	4.5.2	4.5.2
5.4.0	5.4.0	4.5.2	4.5.2
5.4.0	5.4.0	5.4.0	4.5.2
5.4.0	5.4.0	4.5.2	5.4.0
5.4.0	5.0.1.3	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.4.0	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.4.0
5.4.0	5.1.0.3	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.4.0	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.4.0
5.4.0	5.2.0.1	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.4.0	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.4.0
5.4.0	5.4.0	5.4.0	5.4.0

A tabela acima é inteiramente válida para clientes que utilizam apenas serviços SD-WAN. Os clientes que precisem de acesso ao VMware Cloud Web Security ou VMware Secure Access têm de atualizar os seus Edges para a versão 4.5.0 ou posterior.

A versão 4.0.x do VMware SD-WAN chegou ao fim do suporte; a versão 4.2.x e 4.3.x chegaram ao fim do suporte para Gateways e Orchestrators; e a versão 4.5.x está a aproximar-se do fim do suporte para Gateways e Orchestrators.

• A versão 4.0.x chegou ao fim do suporte geral (EOGS) a 30 de setembro de 2022 e ao fim da orientação técnica (EOTG) a 31 de dezembro de 2022. 

• A versão 4.2.x dos Orchestrators e dos Gateways chegou ao fim do suporte geral (EOGS) a 30 de dezembro de 2022 e ao fim da orientação técnica (EOTG) a 30 de março de 2023.

• A versão 4.2.x dos Edges chegou ao fim do suporte geral (EOGS) a 30 de junho de 2023 e chegará ao fim da orientação técnica (EOTG) a 30 de setembro de 2025.

• A versão 4.3.x dos Orchestrators e dos Gateways chegou ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2023.

• A versão 4.3.x dos Edges chegou ao fim do suporte geral (EOGS) a 30 de junho de 2023 e chegará ao fim da orientação técnica (EOTG) a 30 de setembro de 2025.

• A versão 4.5.x dos Orchestrators e dos Gateways chegou ao fim do suporte geral (EOGS) a 30 de setembro de 2023 e chegará ao fim da orientação técnica (EOTG) a 31 de dezembro 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.

Caminhos de atualização do Orchestrator, Gateway e Edge

Seguem-se os caminhos para os clientes que pretendem atualizar o Orchestrator, o Gateway ou o Edge de uma versão mais antiga para a versão 5.4.0.

Orchestrator

Os Orchestrators que utilizam a versão 4.3.0 ou posterior podem ser atualizados para a versão 5.4.0. 

Gateway

A atualização de um Gateway com a versão 4.3.0 ou posterior para a versão 5.4.0 é completamente suportada para todos os tipos de Gateway.

Ao implementar um novo Gateway com a versão 5.4.0, a instância ESXi do VMware tem de ser, pelo menos, da versão 6.7, Atualização 3, até à versão 7.0. A utilização de uma instância ESXi anterior resultará na falha do Serviço dataplane do Gateway ao tentar executar a versão 5.4.0 ou posterior.

Antes de atualizar um Gateway para a versão 5.4.0, a instância ESXi tem de ser atualizada para, pelo menos, a versão 6.7, Atualização 3, até à versão 7.0. A utilização de uma instância ESXi anterior resultará na falha do Serviço dataplane do Gateway ao tentar executar a versão 5.4.0 ou posterior.

Edge

Um Edge pode ser atualizado diretamente para a versão 5.4.0 a partir de qualquer versão 4.x ou posterior.

Novas funcionalidades e melhorias do SASE

Orchestrator bastião, Fase 2

Introduzido pela primeira vez na versão 4.3.0, o VMware SASE oferece grandes melhorias para o Orchestrator bastião na versão 5.4.0. As melhorias da Fase 2 incluem:

• Atualização do software SD-WAN Edge quando o Edge está no estado ativado.

• Reversão para a última configuração válida conhecida no caso de uma falha de promoção do Edge.

• Os eventos de um Edge não promovido são enviados para um VMware SASE Orchestrator privado.

• Geração de um pacote de diagnóstico para um Edge não promovido.

• Atualizações do firmware empresarial no VMware SASE Orchestrator bastião.

Cliente SD-WAN integrado no VMware SASE Orchestrator

Agora, é possível gerir o VMware SD-WAN Client através do VMware SASE Orchestrator, fornecendo uma consola de gestão unificada para gerir soluções de rede, segurança e acesso remoto.

Novas funcionalidades e melhorias do SD-WAN

Suporte da firewall do Edge para FTPv6

A versão 5.4.0 inclui a identificação melhorada de aplicações para os modos FTPv4/FTPv6 Ativo e Passivo ao utilizar a Inspeção profunda de pacotes (DPI) do VMware SD-WAN Edge. Esta DPI melhorada é especialmente útil para clientes que utilizam o modo FTPv6 passivo, que atribui números de porta aleatórios para a transferência de dados e dificulta a identificação do tráfego FTP, visto que não utiliza as portas padrão 20 e 21.

Foram feitas melhorias na visualização e pesquisa do serviço de firewall melhorado

O Serviço de firewall melhorado agora inclui uma vista de tabela de firewall com um campo de comentários e uma nova funcionalidade de pesquisa de regras e objetos de firewall para oferecer uma experiência de utilizador ideal.

Visualização de assinaturas (IDS/IPS) do serviço de firewall melhorado

O Serviço de firewall melhorado inclui a Visualização de assinaturas (IDS/IPS) melhorada que permite uma vista simplificada com visibilidade das assinaturas dos Sistemas de deteção de intrusões (IDS) e dos Sistemas de prevenção de intrusões (IPS) instaladas num VMware SD-WAN Edge juntamente com a versão, os dados e a hora de instalação.

Foram feitas melhorias de alta disponibilidade, Fase 2

A versão 5.4.0 inclui melhorias adicionais para um site implementado utilizando uma topologia de alta disponibilidade com um par de Edges. Estas incluem:

• Alertas: foi adicionado um novo alerta à lista na página Definições de serviço > Alertas e notificações (Service Settings > Alerts & Notifications), O Edge HA falhou (Edge HA Failed). O alerta O Edge HA falhou (Edge HA Failed) é acionado quando o Edge em standby não consegue realizar o heartbeat para o Edge ativo e é marcado pelo Edge ativo como inativo. Este alerta é especialmente útil em implementações HA melhorada em que o Edge em standby também passa tráfego do cliente.

• Compatibilidade entre Edges com Wi-Fi e sem Wi-Fi: antes da versão 5.4.0 do Edge, os modelos Edge que não incluíam um módulo Wi-Fi (510N, 610N, 620N, 640N e 680N) não podiam ser utilizados com um equivalente compatível com Wi-Fi numa implementação HA. Por exemplo, um Edge 640 e um Edge 640N não eram suportados como um par de alta disponibilidade. Na versão 5.4.0 e posterior, este emparelhamento já é suportado.

Num cenário com Edges com Wi-Fi e sem Wi-Fi incompatíveis, o Orchestrator deteta a incompatibilidade do Edge e desativa automaticamente a funcionalidade de Wi-Fi no Edge com Wi-Fi. O registo de incompatibilidade é mostrado nos Eventos (Events) do cliente:

• Identificada uma incompatibilidade da funcionalidade Wi-Fi HA, Wi-Fi desativado (uma incompatibilidade do Wi-Fi do Edge é identificada e o Wi-Fi é desativado no Edge compatível com Wi-Fi).

• A incompatibilidade da funcionalidade Wi-Fi HA deixa de ser vista, Wi-Fi revertido (ambos os Edges são detetados como o mesmo tipo de Wi-Fi e a funcionalidade Wi-Fi é restaurada num Edge com Wi-Fi onde foi desativada anteriormente).

O Hub ou Cluster Interconnect é GA

Introduzido pela primeira vez como uma funcionalidade de acesso antecipado no SD-WAN, versão 5.1.0, o Hub ou Cluster Interconnect é totalmente GA na versão 5.4.0. Esta solução permite que os clientes criem uma arquitetura hierárquica e escalável com conetividade completa de overlay do SD-WAN em hubs na cloud, regionais e de datacenter, fornecendo proteção DMPO (Dynamic Multipath Optimization) completa, visibilidade de ponta a ponta e fiabilidade.

Além do suporte completo para esta funcionalidade, a restrição de contagem de hops anterior de dois é elevada para um número qualificado de quatro hops.

Delegação de prefixo DHCPv6 do IPv6

A versão 5.4.0 adiciona suporte para a Delegação de prefixo DHCPv6 para clientes em que o router de delegação faz parte do alojamento na cloud, numa localização remota ou em cenários em que o ISP do cliente atribui endereços IP. A Delegação de prefixo DHCPv6 inclui novos tipos de endereço para IPv6 e oferece suporte para dois servidores de delegação de prefixo ISP para permitir uma topologia principal e de backup.

Para utilizar a funcionalidade Delegação de prefixo, o Orchestrator, o Gateway e o Edge devem estar a utilizar uma versão de software 5.4.0 ou posterior. Não há suporte para Delegação de prefixo para utilização num Edge com a versão 5.2.0 ou anterior e, se um Edge com a versão 5.2.0 ou anterior estiver configurado para Delegação de prefixo, a funcionalidade não funcionará conforme esperado.

Além disso, um Edge com a versão 5.2.0 ou anterior configurado com a Delegação de prefixo não poderá ser atualizado para a versão 5.4.0. Assim, se estiver a atualizar um Edge 5.2.0 ou anterior para 5.4.0 ou posterior, verifique se a Delegação de prefixo não está a ser utilizada nesse Edge.

Suporte para o driver bifurcado Mellanox do Microsoft Azure Virtual Edge

O VMware SD-WAN fornece suporte para Rede acelerada (SR-IOV) para o Microsoft Azure Virtual Edge e inclui suporte para NICs Mellanox ConnectX-4 e ConnectX-5. Ao ativar o SR-IOV numa interface Azure Virtual Edge, a melhoria é ativada automaticamente no Edge.

A Rede acelerada pode ser ativada ou desativada através do portal do Azure, da CLI do Azure ou do Azure PowerShell.

Esta melhoria não inclui suporte para NICs Mellanox ConnectX-3

Run-To-Completion FastPath no Edge, Fase 3

O modelo Run-To-Completion é uma otimização de software que aumenta o desempenho em Edges e Gateways, o que resulta numa melhoria na eficiência geral da solução SD-WAN.

Notas importantes

Alteração do comportamento da NAT do lado da LAN

A partir da versão 4.5 e seguintes, quando uma NAT do lado da LAN é configurada para traduções de muitos para um através da Port Address Translation (PAT), o tráfego iniciado na direção oposta pode permitir acesso inesperado a endereços fixos com base na máscara externa e no endereço IP original. Este novo comportamento aplica-se às regras NAT de destino (DNAT), NAT de origem (SNAT) e NAT de origem e destino (NAT S+D).

Por exemplo, uma regra SNAT com uma rede interna de 192.168.1.0/24 e um endereço externo de 10.1.1.100/32 permite a tradução de fora para dentro para 192.168.1.100.

Para resolver este novo comportamento, agora, o SD-WAN bloqueia o tráfego quando é iniciada uma ligação na direção inversa da PAT.

Para restaurar o comportamento original, o utilizador tem de configurar duas regras do mesmo tipo que a regra original (SNAT, DNAT, S+D NAT) numa ordem específica. Por exemplo, com o cenário SNAT anterior, o utilizador tem de configurar o seguinte:

1. Regra SNAT com uma rede interna de 192.168.1.100/32 e um endereço externo de 10.1.1.100/32

2. Regra SNAT com uma rede interna de 192.168.1.0/24 e um endereço externo de 10.1.1.100/32

Se a regra original for uma DNAT ou S+D NAT, o utilizador precisará de duas regras DNAT ou S+D NAT com a mesma estrutura e ordem.

Na versão 4.5.0 a 5.2.0, o utilizador poderá determinar se os fluxos são ignorados para esse tipo de tráfego nos registos dispcnt de um pacote de diagnóstico ao procurar o contador lan_side_nat_reverse_pat_drop.

A partir da versão 5.4.0, os utilizadores podem encontrar seis contadores separados nos registos:

• lan_side_nat_rev_pat_drop_snat1

• lan_side_nat_rev_pat_drop_snat2

• lan_side_nat_rev_pat_drop_dnat1

• lan_side_nat_rev_pat_drop_dnat2

• lan_side_nat_rev_pat_drop_sdnat1

• lan_side_nat_rev_pat_drop_sdnat2

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 forçar um modo de velocidade e 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).

Idiomas disponíveis

O VMware SASE Orchestrator com a versão 5.4.0 está localizado nos seguintes idiomas: alemão, checo, chinês simplificado, chinês tradicional, coreano, espanhol, francês, grego, inglês, italiano, japonês e português (Portugal).

Alterações à API do Orchestrator

Alterações à API do Orchestrator desde a versão 5.3.0

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

Veja a seguir os problemas que afetam os utilizadores da API v1:

Pedido	Sintoma/Descrição
Problema conhecido 118684	A APIv1 não inclui os IDs incrementais no payload para referência do utilizador. Como parte da migração contínua para um novo sistema de gestão de bases de dados, o VMware SD-WAN substituiu alguns IDs incrementais, como edgeId, por IDs lógicos. Esta alteração é necessária porque a maioria das interfaces agora utiliza IDs lógicos. Trata-se de um problema puramente cosmético e pode mapear com segurança o edgeId de chamada para o edgeLogicalId de retorno.
Problema conhecido 123867	As APIs de série e as métricas de ligação devolvem um erro quando são chamadas sem uma lista de métricas. Este é um problema que será corrigido numa versão futura. Para contornar este problema, pode enviar o pedido de API com uma lista dos campos de métricas que deseja devolver. Isto garante que recebe os dados necessários, mesmo que a API devolva uma mensagem de erro. Este problema não afeta a funcionalidade das APIs, portanto pode continuar a utilizá-las para recuperar dados.
Problema conhecido 127994	A especificação Swagger está a comunicar um erro de esquema devido a um additionalProperty: title no esquema de resposta. Trata-se de um problema cosmético e não afeta a funcionalidade da API. Este problema será resolvido numa versão futura e a API poderá continuar a ser utilizada para recuperar dados, mesmo que o Orchestrator receba este erro de esquema.
Problema 127995 resolvido	A especificação Swagger está a comunicar um erro de esquema devido a um tipo incorreto no campo de itens do esquema de resposta. Trata-se de um problema cosmético e não afeta a capacidade de a API recuperar dados. O erro pode ser ignorado com segurança. Este problema foi resolvido na versão 5.4.0.

Para referência, o registo de alterações da API completo está disponível para transferência em developer.vmware.com (ver “API v1 do VMware SD-WAN Orchestrator”).

Alterações à API v2 do VMware SASE Orchestrator

Não há novas APIs API v2 desde a versão 5.3.0.

Veja a seguir as alterações na API v2 entre a versão 5.3.0 e 5.4.0.

Pedido	Sintoma/Descrição
Problema 116610 resolvido	Os utilizadores não conseguem adicionar uma nova interface de retorno através da APIv2. A estrutura de esquema para a interface de retorno na APIv2 não permitia interfaces nomeadas pelo ID de interface. Portanto, a atualização da interface de retorno falha.
Problema 129679 resolvido	Os clientes não poderão atualizar o módulo de definições do dispositivo do Edge com as definições do dispositivo Edge APIv2 PATCH quando o módulo de definições do dispositivo do Edge tiver subinterfaces configuradas. Quando as subinterfaces são configuradas no módulo de definições do dispositivo do Edge, uma chamada de API para a API de definições de dispositivo Edge v2 PATCH fará com que o pedido fique pendente num estado “Aceite” (Accepted) para sempre e acabe por expirar. Como tal, os clientes não verão nenhuma alteração refletida no módulo de definições do dispositivo do Edge no Orchestrator.

Documentação do Programador

Toda a documentação da API VMware SASE/SD-WAN reside no Portal de documentação do programador em https://developer.vmware.com/apis.

Histórico de revisões do documento

16 de novembro de 2023. Segunda edição.

• Foi adicionada uma nova compilação rollup R5401-20231115-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a primeira compilação rollup do Orchestrator e é a nova compilação GA predefinida do Orchestrator para a versão 5.4.0.

• A compilação R5401-20231115-GA do Orchestrator inclui as correções para os problemas 117138, 123078, 123387, 125309, 125964, 126602, 127727, 127774, 127843, 127904, 128017, 128277, 128279, 128357, 128765, 129061, 129494, 129584, 129756, 129765, 129894, 130153, 130877 e 131846, sendo que cada uma delas está documentada nesta secção.

• Foi adicionada uma compilação R5400-20231108-GA-125647 atualizada do Edge à secção Problemas resolvidos do Edge/Gateway. Esta é uma atualização à compilação GA R5400-20231009-GA original do Edge e é a nova compilação GA predefinida do Edge/Gateway para a versão 5.4.0.

  A compilação R5400-20231108-GA-125647 do Edge inclui a correção para o problema 125647, que se encontra documentada nesta secção.

  • A compilação anterior da versão 5.4.0 do Edge foi preterida em favor da R5400-20231108-GA-125647.

  • Os clientes que atualizam para a versão 5.4.0 só devem atualizar para a R5202-20231107-GA-125647.

  • Os clientes que já utilizam com êxito a compilação 5.4.0 original do Edge não têm de atualizar os Edges para a R5400-20231108-GA-125647.

19 de outubro de 2023. Primeira edição.

Problemas resolvidos do Edge e do Gateway

• Resolvido na versão R5400-20231108-GA-125647 do Edge
• Resolvido na versão R5400-20231009-GA do Edge e do Gateway

Resolvido na versão R5400-20231108-GA-125647 do Edge

A compilação R5400-20231108-GA-125647 do Edge foi lançada a 14/11/2023 e é a uma atualização à compilação GA do Edge para a versão 5.4.0.

Esta compilação do Edge atualizada resolve o problema crítico abaixo desde a compilação GA R5400-20231009-GA original.

• Todas as compilações anteriores da versão 5.2.0 do Edge foram preteridas em favor da R5202-20231107-GA-125647.

• Os clientes que atualizam para a versão 5.2.0 só devem atualizar para a R5202-20231107-GA-125647.

• Os clientes que já utilizam com êxito uma compilação do Edge 5.2.0.x não têm de atualizar os Edges para a R5202-20231107-GA-125647.

• Problema 125647 resolvido: num site implementado com um modelo Edge 520 ou 540, quando um Edge é atualizado para a versão 5.2.0, os utilizadores clientes ligados ao Edge através de uma porta LAN podem registar uma perda total de conetividade.

  Reinicializar o Edge 520/540 não resolve o problema nem altera o Edge para uma versão de software mais antiga depois de este ter sido atualizado para a versão 5.2.0. Quando a consola do Edge é desativada nas definições Segurança do Edge > Acesso de consola (Edge Security > Console Access) na página de configuração Firewall do Orchestrator (que é a configuração predefinida para qualquer Edge), o driver que gere a LAN1 através das portas LAN8 do Edge 520 ou 540 não se configura corretamente, fazendo com que essas portas não sejam criadas.

  Num Edge sem uma correção para este problema, um cliente pode impedir que este problema ocorra e/ou restaurar a conetividade nas portas LAN num Edge afetado. Para tal, poderá: navegar para Configurar > Edge/Perfil > Firewall > Segurança do Edge (Configure > Edge/Profile > Firewall > Edge Security) e, em Acesso de consola (Console Access), clicar em Ativar (Enable) e Guardar alterações (Save Changes).

  

  A alteração desta configuração requer uma reinicialização do Edge que demora ~2-3 minutos. Se possível, execute esta alteração numa janela de manutenção.

Resolvido na versão R5400-20231009-GA do Edge e do Gateway

A compilação R5400-20231009-GA do Edge e do Gateway foi lançada a 23/10/2023 e resolve os seguintes problemas desde a compilação R5202-20230725-GA do Edge e do Gateway.

A versão 5.4.0 contém todas as correções do Edge e do Gateway documentadas nas Notas de versão 5.2.0 até à versão 5.2.0.2 (R5202-20230725-GA).

• Problema 69641 resolvido: na empresa de um cliente que utiliza uma ou mais políticas empresariais que incluem limites de taxa, o cliente pode observar quedas de pacotes em todos os fluxos, mesmo naqueles que não estão relacionados com os fluxos de políticas empresariais de taxa limitada e noutros segmentos e pares.

  Definir uma política empresarial de taxa limitada e enviar tráfego de maior procura (mais do que o limite) com um elevado número de fluxos resulta na eliminação de pacotes de outros fluxos (mesmo de outros segmentos e pares), devido ao facto de o limite de buffer do programador de rede ser atingido.

  Numa empresa cujos Edges não têm uma correção para este problema, a solução alternativa será remover a configuração de limite de taxa e, em vez disso, reclassificar o tráfego correspondente à regra com o menor valor possível (baixo, em massa).

• Problema 74422 resolvido: em casos de alta disponibilidade, o Edge poderá ficar offline se apenas o Edge em standby tiver uma ligação WAN ativa e um endereço IP válido.

  Este problema ocorre quando uma ligação WAN tem o DHCP ativado e apenas o Edge em standby tem uma ligação WAN disponível. Quando a ligação WAN em standby recebe um endereço IP do servidor DHCP, envia os detalhes da interface para o Edge ativo. O Edge ativo faz uma chamada para adicionar o endereço IP como um caminho, no entanto, essa função não adiciona o caminho ao kernel do Linux. A função do Edge só adiciona o caminho à FIB (base de informações de encaminhamento). Como tal, o processo de gestão de Edges gera um erro, pois não há nenhum caminho presente na tabela de caminhos do kernel do Linux para que o pacote saia e o site esteja efetivamente offline.

• Problema 79598 resolvido: na empresa de um cliente que utiliza o Zscaler com túneis redundantes, numa recuperação automática do túnel principal para o secundário, o tráfego muda para o túnel principal mais cedo do que o esperado.

  O comportamento esperado é que o túnel Zscaler principal seja ativado e que o tráfego continue a utilizar o túnel secundário durante mais 30 minutos antes de o tráfego ser direcionado para o túnel principal. Tal garante que o túnel principal fique estável e tenha menos probabilidade de voltar a ficar inativo, forçando outra recuperação automática de tráfego. Com este problema, o tráfego é direcionado para o túnel principal em menos de 30 minutos.

• Problema 91164 resolvido: um Edge Hub com alta disponibilidade configurada pode não encaminhar o tráfego de backhaul de Internet após uma recuperação automática HA.

  O Edge em standby não define o caminho de destino para fluxos de backhaul de Internet quando o fluxo de backhaul é configurado para encaminhar através de um caminho estático em que o overlay WAN está desativado.

• Problema 92421 resolvido: quando os overlays público e privado são configurados na mesma interface Edge com diferentes etiquetas de VLAN personalizadas, existe a possibilidade de se verificar uma queda do tráfego underlay encaminhado.

  Quando os overlays público e privado são configurados na mesma interface com diferentes etiquetas de VLAN personalizadas, o Edge pode memorizar as entradas ARP com as etiquetas de VLAN erradas, o que faz com que se verifique uma queda do tráfego.

• Problema 96334 resolvido: num VMware SASE Orchestrator em que o endereço IP muda com frequência, os VMware SD-WAN Edges podem perder contacto com o Orchestrator e ser registados como offline.

  Neste cenário, em que o endereço IP do Orchestrator é alterado com frequência, os Edges estão a responder a cada alteração de endereço IP do Orchestrator alterando a origem do tráfego de gestão de uma interface de retorno para o endereço IP da porta GE1, mesmo quando o Orchestrator está configurado para utilizar exclusivamente a interface de retorno como origem. Como tal, os Edges perdem contacto com o Orchestrator e, embora isso não afete o tráfego do cliente, este problema impedirá que as atualizações de configuração e a monitorização funcionem conforme esperado.

• Problema 99162 resolvido: se um VMware SD-WAN Edge tiver flaps de túnel frequentes, tal poderá resultar num aumento no consumo da memória e possivelmente levar à reinicialização defensiva do Edge para recuperar a memória.

  A memória do Edge afetada é o objeto vc_edge_route, que o serviço Edge não limpa após cada instância de um túnel ser destruída e depois reconstruída. Como qualquer fuga de memória, se for consumida memória suficiente do Edge por esta fuga, o Edge acionará um reinício do serviço para limpar a memória e isso poderá interromper o tráfego do utilizador durante 10 a 15 segundos.

• Problema 104776 resolvido: no caso de um cliente que configura uma interface VMware SD-WAN Edge para PPPoE, quando as definições de overlay WAN dessa interface incluem a definição 802.1P, o Edge inclui os bits PRI 802.1P no tráfego de saída.

  O Edge não inclui a opção configurável para o netifd definir “mapeamentos de prioridade de ENTRADA” para interfaces PPPoE e, como tal, o Edge não marca esses pacotes com PRI.

• Problema 104786 resolvido: na empresa de um cliente implementada com uma topologia Hub ou Cluster Interconnect, o reequilíbrio automático dos túneis entre dois clusters de interligação não funciona.

  O reequilíbrio dos clusters interligados não ocorre com o aumento da pontuação do cluster ou do flap BGP, o que deveria ocorrer e pode causar problemas de tráfego devido ao desequilíbrio na utilização dos túneis.

• Problema 105034 resolvido: a consulta SNMP para a CPU e a memória de um VMware SD-WAN Edge obtém sempre um zero como valor de resposta.

  A consulta SNMP para a CPU e a memória como parte das estatísticas do estado de funcionamento do Edge obtém sempre um valor de resposta igual a zero. Como resolução, a Utilização da CPU (CPU utilization) agora é denominada Média de carga da CPU (CPU load average) e a utilização da memória também é preenchida como resposta.

• Problema 106160 resolvido: num servidor DNS configurado no Edge e um Gateway de próximo hop definido para uma interface Edge para a qual os clientes consultam o servidor DNS, não haverá resposta.

  O pacote de pedido DNS é recebido pelo servidor DNS do Edge conforme esperado. No entanto, o pacote de resposta faz uma pesquisa de tabela de caminhos com base no controlo de uma ligação iptables e localiza o endereço IP do gateway do próximo hop e resolve o endereço MAC. Como tal, o pacote de resposta DNS utilizará o endereço MAC do Gateway, não o remetente.

• Problema 106992 resolvido: na empresa de um cliente implementada com uma topologia Hub ou Cluster Interconnect, o cliente pode observar que os clusters de hub não podem formar overlays entre si.

  Os membros do cluster de hub com interligação ativada talvez não consigam estabelecer overlays devido ao mapeamento obsoleto do cluster de hub. A única forma de corrigir este problema será desativar e reativar a interligação nos clusters de hub.

• Problema 107550 resolvido: em empresas de clientes em que os Destinos Não-SD-WAN via Gateways são implementados, os utilizadores podem observar a queda de alguns pacotes encriptados IPsec no caminho.

  A implementação atual utiliza um valor interno de tempo de vida (TTL) do cabeçalho IP, o que não corresponde ao requisito RFC. Como tal, o valor TTL deve ser construído e, se o originador do pacote utilizar um valor TTL baixo, existirá a possibilidade de este pacote não chegar ao seu destino.

• Problema 108111 resolvido: quando um utilizador operador ou parceiro tenta depurar um VMware SD-WAN Gateway através do comando debug.py --bgp_agg_dump, o comando não terá uma cadeia de ajuda adequada.

  A cadeia de ajuda explica que argumentos são utilizados (por exemplo: [[v4 | v6 | all] ...]]) e, com este problema, essa cadeia está em falta para o comando de depuração.

• Problema 109830 resolvido: as combinações de certos clientes e servidores da VPN do Protocolo PPTP (Point-to-Point Tunneling Protocol) podem não conseguir restabelecer imediatamente uma ligação após esta ser interrompida ao utilizar NAT 1:1 com o servidor PPTP atrás do Edge e do cliente na Internet.

  Foi confirmado que este problema ocorre com um cliente Windows Server 2016 e Windows 10, mas também pode ocorrer com outras versões. O problema é causado pelo servidor que está a reutilizar o mesmo call-id PPTP para a nova ligação, enquanto o cliente utiliza um novo call-id. Quando o call-id do servidor é reutilizado para a nova ligação, a firewall não o identifica como tal.

  Sem uma correção para este problema, o utilizador pode remover a ligação PPTP obsoleta da tabela NAT para restaurar a conetividade.

• Problema 112115 resolvido: um VMware SD-WAN Edge com uma carga de CPU elevada pode registar uma falha no Serviço dataplane e ser reiniciado para recuperar.

  Sob condições de CPU elevada, podem ocorrer várias falhas de serviço desencadeadas por um monitor mutex devido ao facto de um thread de menor prioridade adquirir o bloqueio do anel de depuração. A resolução para este problema passa por uma melhoria no Dataplane que torna esse thread livre de bloqueios e de esperas.

• Problema 112509 resolvido: um VMware SD-WAN Edge configurado para utilizar uma VNF pode registar uma falha do Serviço dataplane e ser reiniciado para recuperar.

  O problema tem origem no processamento do SKB (memória intermédia de rede). Em certos casos, a verificação da alocação do SKB está em falta, o que pode levar à falha do serviço Edge.

• Problema 113877 resolvido: no caso de clientes que configuram a LAN BGP/GRE, aqueles que utilizam GRE TGW sofrerão flaps do BGP e uma interrupção de tráfego no túnel secundário TGW em todos os segmentos quando a configuração BGP para o GRE TGW é modificada no segmento global.

  Quando o cliente altera uma configuração BGP do GRE TGW no segmento global, o túnel secundário no segmento global e noutros segmentos sofre um flap, conduzindo a uma redefinição e reconvergência da ligação BGP e a uma interrupção do tráfego. A ligação BGP formar-se-á novamente e o tráfego será restaurado.

• Problema 114529 resolvido: para modelos Edge LTE (510-LTE, 610-LTE), quando um utilizador não define as configurações de CELL no Orchestrator mesmo depois de ativar CELL1/CELL2 e não há operadora e configurações predefinidas selecionadas, o Edge gera um erro de configuração.

  Se um utilizador ativar uma interface LTE Edge CELL1/CELL2 na página Configurar > Edge > Dispositivo > Interface (Configure > Edge > Device > Interface) e não selecionar nenhuma operadora/rede na lista, este campo abrirá o Edge como vazio e, quando for lido, o Edge gerará um erro a informar que não é de um dos SPNs disponíveis. Este erro pode ser visto na secção Eventos (Events) do Orchestrator.

• Problema 114659 resolvido: o comando de depuração tcpdump.sh não funciona num VMware SD-WAN Gateway.

  O processo de segurança AppArmor do Gateway bloqueia o acesso aos terminais /dev/pts/*. Isso faz com que o processo vctcpdump seja encerrado e o tcpdump.sh não capture nenhuma informação sobre stdout.

  Num Gateway sem uma correção para este problema, a solução alternativa passa por executar o comando tcpdump.sh-w para guardar a saída num ficheiro, uma vez que ainda funciona.

• Problema 114854 resolvido: quando um utilizador está a resolver problemas de um VMware SD-WAN Edge, modelo 610, com DPDK ativado, executar uma captura de pacotes do Orchestrator ou utilizar tcpdump.sh ou vctcpdump mostra que a etiqueta de VLAN está ausente para o tráfego de retorno.

  A falta de etiquetas de VLAN no tráfego de retorno afeta a capacidade de o utilizador resolver com êxito um problema de rede com qualquer versão de um Edge 610.

• Problema 114938 resolvido: ao consultar Monitorizar > Edges > Destinos (Monitor > Edges > Destinations) para a empresa de um cliente, o utilizador pode observar um nome de domínio incorreto para um destino.

  Estes nomes de anfitrião inválidos podem encher a cache DNS do Edge e causar eventos DNS máx. alcançado (Max DNS reached), pelo que não será possível adicionar nomes de anfitrião válidos depois de isto ocorrer. O problema é causado pela Inspeção profunda de pacotes (DPI) do Edge que adiciona nomes de anfitrião inválidos (por exemplo, Endereço IP ou Endereço IP:Porta) na cache DNS do Edge.

  

• Problema 114988 resolvido: a mensagem “Pacote demasiado grande” (Packet Too Big) do ICMPv6 não é recebida de ou através de um VMware SD-WAN Gateway.

  O caminho de dados do Gateway consome todas as mensagens “Pacote demasiado grande” (Packet Too Big) do ICMPv6 localmente. A correção garante que o Gateway envia o destino adequado.

• Problema 115148 resolvido: quando um cliente implementa um Serviço de Segurança na Cloud com túneis redundantes (por outras palavras, ativos e em standby) e a Verificação de estado de funcionamento de L7 é ativada, se o túnel CSS principal ficar inativo e depois ativo, o túnel CSS em standby poderá permanecer ativo.

  Se o túnel em standby estiver ativo quando a verificação de estado de funcionamento de L7 for ativada e, em seguida, esta funcionalidade for desativada antes de o túnel CSS principal voltar a ficar ativo, o túnel em standby poderá permanecer num estado ativo indefinidamente. A causa do problema é que, embora a Verificação de estado de funcionamento de L7 esteja desativada, o Gateway verificará o estado de L7 para o túnel principal e o seu estado será lido como inativo, e, como tal, o Gateway conclui que o túnel principal está inativo e manterá o túnel em standby.

  Num Edge sem uma correção para este problema, se um utilizador executar Ações Remotas > Reinicialização do Serviço do Edge (Remote Actions > Edge Service Restart), resolverá o problema para essa localização.

• Problema 115225 resolvido: quando um VMware SD-WAN Edge encontra um grande número de flaps de túnel, isso pode provocar uma maior utilização da memória devido a uma fuga de memória.

  Ao examinar os registos, o utilizador poderá observar um aumento no objeto de memória vc_edge_route onde há vários flaps de túnel como resultado de fugas de memória relacionadas com o caminho do Edge.

• Problema 115262 resolvido: quando a empresa de um cliente utiliza o BGP para o routing, a vizinhança BGP com um endereço IP secundário pode não ser ativada num VMware SD-WAN Edge.

  Quando um utilizador configura o vizinho BGP primeiro e, em seguida, configura o endereço IP secundário correspondente numa interface VLAN, a sessão BGP não é ativada porque a interface BGP não é atualizada com a remoção/adição do endereço IP secundário numa interface VLAN.

• Problema 115604 resolvido: um VMware SD-WAN Edge ou Gateway pode registar uma falha no Serviço dataplane e gerar um núcleo com uma afirmação no início de sessão.

  Quando um Edge ou Gateway processa um pacote corrompido, o software pode atingir uma afirmação onde o comprimento do pacote do utilizador atual é superior à memória intermédia do pacote interno. Espera-se que o Gateway descarte esse tipo de pacote e impeça que o mesmo seja enviado para o Edge, mas em vez disso processa-o e isso resulta numa falha do serviço e reinicialização.

• Problema 115869 resolvido: os túneis são restabelecidos para um VMware SD-WAN Gateway durante o respetivo processo de atualização.

  Num ambiente dimensionado onde há milhares de túneis e pares ligados a um Gateway, quando um Gateway é atualizado, o tráfego muda para o Gateway secundário de modo a garantir um curto período de inatividade e retomar o fluxo de tráfego rapidamente. Quando o script de atualização está a ser executado no Gateway em atualização (de 4.5.1 para 5.2.0, 5.0.1 para 5.2.0 ou 5.1.0 para 5.2.0), no meio da execução do script de atualização, os túneis começam a voltar ao Gateway que está a ser atualizado e o tráfego muda novamente do Gateway secundário para o Gateway que está a ser atualizado. E, em seguida, quando o script termina, mais uma vez o Gateway tem de ser reiniciado e, mais uma vez, o tráfego é trocado para um Gateway secundário. Isto pode causar grandes interrupções de tráfego do cliente para o tráfego do tipo multicaminho que utiliza o Gateway.

  Num gateway sem uma correção para este problema, a solução alternativa passa por mover o reinício do vc_proc_mon do script pós-instalação para depois de a atualização ser concluída.

• Problema 115904 resolvido: quando um utilizador aciona um pacote de diagnóstico num VMware SD-WAN Edge utilizando o VMware SASE Orchestrator, o Edge pode registar uma falha no Serviço dataplane, gerar um núcleo e ser reiniciado para recuperar.

  O utilizador pode gerar um pacote de diagnóstico do Edge na página SD-WAN > Diagnóstico > Pacote de diagnóstico (SD-WAN > Diagnostics > Diagnostic Bundle). Quando esta ação é executada, pode ocorrer uma condição race entre dns_name_cache (adição e/ou eliminação) e a cache de nomes DNS, o que faz com que o serviço Edge tente aceder a um elemento em utilização ou eliminado, o que leva a uma falha do serviço com um motivo SIGSEGV ou SIGBUS.

• Problema 116049 resolvido: o estado VPN de uma ligação WAN configurada como backup pode ir para um estado DEAD em vez do estado STANDBY esperado.

  O impacto para o cliente é reduzido porque a funcionalidade da ligação WAN de backup (ligação que se torna ATIVA quando outros caminhos ficam inativos) permanece inalterada. No entanto, o estado da IU apresentado na ligação WAN como DEAD pode causar confusão ao cliente e, se a ligação WAN de backup estiver de facto inativa, o cliente não conseguirá saber através da página Edge > Monitorizar (Edge > Monitor) quando esse problema ocorrer.

  Este problema pode ocorrer quando a empresa está ligada a um Gateway de parceiro e o endereço IP de handoff BGP configurado não é um endereço IP de nenhuma interface Edge nesse segmento. Nesse cenário, as mensagens de verificação da ligação de backup do Edge podem ser ignoradas. Como tal, as ligações WAN configuradas como backups para os Edges podem ser marcadas como DEAD em vez de STANDBY mesmo que a ligação esteja ativa.

• Problema 116059 resolvido: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade em que são utilizadas VNFs, a conetividade com uma VNF de Edge em standby falha no gestor de VNF presente na VLAN de gestão de VNF.

  Quando um gestor de VNF é implementado na VLAN de gestão de VNF, uma entrada de endereço MAC errada pode ser memorizada na base de dados de encaminhamento (FDB) da bridge de gestão de VNF em standby e essa entrada persistirá mesmo depois de as portas da bridge em standby serem definidas para um estado desativado. Como tal, a conetividade VNF do Edge em standby falha no gestor de VNF.

• Problema 116199 resolvido: na empresa de um cliente com configuração Hub e Cluster Interconnect, quando o túnel entre um Spoke Edge e um Hub ou Cluster fica inativo, os caminhos não podem ser revogados a partir dos Spoke Edges remotos.

  Este problema pode afetar o tráfego do cliente que utiliza esses caminhos obsoletos e só pode ser resolvido temporariamente iniciando novamente os caminhos.

• Problema 116257 resolvido: no caso de um VMware SD-WAN Edge ligado através de um Gateway de parceiro em que um handoff NAT está configurado para um servidor remoto, o tráfego de retorno para o Edge pode ser perdido a partir desse servidor.

  Se o tráfego não for inicialmente encriptado do Edge para o servidor remoto e, em seguida, atualizado com um sinalizador encriptado, assim que o caminho for atualizado, o tráfego inverso será eliminado no Edge devido a uma falha na pesquisa de caminhos.

  O problema pode ser resolvido temporariamente ao eliminar os fluxos no Edge afetado.

• Problema 116368 resolvido: os registos de routing num VMware SD-WAN Gateway podem atingir a capacidade e não acumular entradas adicionais.

  Este problema é causado pelo software de routing do Gateway que não possui a configuração de rotação de registos, cuja finalidade é rodar os registos de routing antes de atingirem a capacidade para que possam ser adicionadas novas entradas de registo. Sem esta configuração, os registos de routing não são rodados e os operadores e parceiros podem perder entradas de registo críticas para um Gateway.

• Problema 116428 resolvido: na implementação de um cliente em que vários segmentos estão configurados e cada segmento não global tem um nome personalizado, ao executar Diagnóstico remoto > Teste de ping (Remote Diagnostics > Ping Test), o menu pendente para escolher uma interface não mostrará o nome personalizado de cada segmento.

  Em vez do nome personalizado de cada segmento não global, o utilizador verá um nome genérico com um número: Segmento 1 (Segment 1), Segmento 2 (Segment 2), etc. Este é o resultado da codificação por parte do Edge do nome do segmento para cada segmento não global.

  

• Problema 116827 resolvido: um VMware SD-WAN Edge pode registar uma falha do Serviço dataplane e ser reiniciado para recuperar da condição.

  O Edge pode registar este problema devido a uma condição race durante o arranque do Edge, o que faz com que o serviço Edge falhe devido a dados não inicializados.

• Problema 116894 resolvido: a NAT 1:1 não funciona corretamente quando o endereço IP externo e o endereço IP de origem estão na mesma sub-rede.

  Com esta configuração da NAT 1:1, o Edge altera a porta de origem durante a tradução NAT e o resultado é a queda de tráfego que corresponde a esta regra para o tráfego de entrada.

• Problema 116916 resolvido: os caminhos do Edge para Edges e Gateways pares podem ficar inativos após a adição ou eliminação de um caminho predefinido do kernel IPv6 para qualquer destino através de uma interface Edge que é utilizada pelo processo de gestão de Edges.

  Os caminhos do Edge podem ficar inativos após a adição ou eliminação de um caminho predefinido do kernel IPv6 que envolva qualquer interface utilizada pelo processo de gestão de Edges para formar caminhos com outros nós (ou seja, Edge ou Gateways).

  Se tiver este problema sem uma correção, o utilizador terá de remover o caminho IPv6 e reiniciar o serviço.

• Problema 116925 resolvido: o tráfego FTP pode ser classificado incorretamente como TCP genérico pelo motor de inspeção profunda de pacotes (DPI) do VMware SD-WAN Edge.

  Quando este problema ocorrer, terá um impacto significativo para um cliente que esteja a utilizar uma política empresarial ou uma regra de firewall que se destina a corresponder ao tráfego FTP, uma vez que a regra não funcionará.

  O tráfego de dados FTP é classificado como APP_TCP em vez de APP_FTP_DATA. Tal deve-se ao facto de os fluxos de controlo FTP serem removidos do contexto do motor DPI assim que a classificação é efetuada. Mas para que o tráfego de dados FTP seja classificado corretamente, o fluxo deve persistir no motor DPI.

• Problema 117037 resolvido: no caso de um cliente que utiliza uma topologia Hub/Spoke na qual sejam utilizadas várias ligações WAN para enviar e receber tráfego do Spoke Edge para o Hub Edge, os clientes podem observar um desempenho inferior ao esperado para o tráfego que é direcionado pelas Políticas empresariais, porque as ligações WAN não agregam a largura de banda da ligação WAN.

  O SD-WAN utiliza um contador para contabilizar o número de pacotes armazenados em buffer numa fila de nova sequenciação. Este contador é gerido por par e utilizado para garantir que só os pacotes 4K são armazenados em buffer por par. Sob algumas condições, este contador pode tornar-se negativo. Antes da versão 4.2.x, quando este contador ficava negativo, o respetivo contador era imediatamente reposto a 0 depois de remover os pacotes na fila de nova sequenciação. No entanto, a partir da versão 4.3.x, este contador é atualizado automaticamente para garantir que permanece dentro dos limites esperados.

  O resultado desta alteração no comportamento pode causar casos em que a contagem do contador está incorreta e a fila de nova sequenciação pode permanecer num número muito alto ao qual o SD-WAN reage removendo cada pacote. Esta ação não só impede a agregação de largura de banda, como também pode reduzir a eficácia dos fluxos que, de outra forma, ficariam numa única ligação.

  Nos Edges sem uma correção para o problema, a solução será configurar políticas empresariais que direcionem o tráfego correspondente para uma única ligação obrigatória.

• Problema 117314 resolvido: quando já existe um fluxo ICMP entre um par de endereços IP de origem e de destino, as regras de firewall que utilizem um Grupo de objetos/Grupo de serviços (tipo e código) para filtrar pacotes ICMP poderão não funcionar.

  Como parte da revisão da funcionalidade da firewall, as alterações introduzidas para o armazenamento em cache do tipo e do código ICMP foram revertidas, o que afetou as regras de firewall que utilizavam um Grupo de serviços com um tipo e código ICMP (por exemplo, Tipo de redirecionamento 5 e Código 0 do ICMP). Se um fluxo já estiver presente entre um endereço IP de origem e de destino, o tráfego ICMP que deve corresponder às regras desse fluxo não será respeitado e apenas os primeiros pacotes de uma sessão corresponderão às regras de firewall. O problema afeta os fluxos ICMP IPv4 ou IPv6.

  Remover os fluxos para criar novos fluxos ICMP corrigirá temporariamente o problema.

• Problema 117320 resolvido: no caso de um cliente em que a firewall com estado está ativada e o Syslog ativado, as mensagens do Syslog para tráfego que corresponda a uma regra NAT do lado da LAN não incluem o endereço IP de origem.

  Espera-se que uma mensagem Syslog completa para qualquer tráfego inclua o endereço IP de origem, especialmente para o tráfego que está a ser alvo de NAT.

• Problema 117831 resolvido: as regras de firewall predefinidas do VMware SD-WAN Gateway impedem que o agente Linux Azure comunique com os recursos de infraestrutura do Azure após o arranque do serviço SD-WAN.

  Isto não afeta a funcionalidade SD-WAN, mas algumas métricas podem estar em falta no Portal do Azure para a VM do Gateway.

  O agente Linux do Azure requer comunicação de saída através das portas 80/TCP e 32526/TCP com o WireServer (168.63.129.16). Depois do arranque do serviço Gateway, a porta 32526 será bloqueada.

• Problema 117838 resolvido: um VMware SD-WAN Edge pode registar uma falha no Serviço dataplane, gerar um núcleo e ser reiniciado para recuperar.

  O problema pode ocorrer quando o Edge recebe um pacote ike com uma versão incompatível quando comparado com o ike_ds. O problema é causado quando o serviço Edge está a processar pacotes de versão incompatíveis e utiliza um bloqueio mutex para modificar um valor de cookie no ike_ds, mas, se ocorrer uma incompatibilidade de versão, o Edge acionará uma eliminação de associação de segurança (SA) que tentará novamente utilizar o mutex no mesmo ike_ds. O resultado é um bloqueio do Edge e uma falha no serviço com o consequente reinício.

• Problema 117943 resolvido: num VMware SD-WAN Edge com capacidade Wi-Fi, a seleção automática de canais para alguns países pode resultar no Edge escolher canais que resultam num fraco desempenho do Wi-Fi ou até numa falha completa do Wi-Fi.

  Em alguns países, como a Grã-Bretanha, o Wi-Fi demora muito tempo a ser configurado para a banda de 5 GHz (ou pode até nem aparecer). A seleção automática de canal para a banda de 5 GHz pode acabar por selecionar canais inadequados em certos países – canais de muito baixa potência ou canais que exigem deteção de radar (o que pode atrasar ou falhar a inicialização).

  Num Edge sem uma correção para este problema, ao selecionar a banda de 5 GHz num país europeu, configure o canal de rádio para 36, 40, 44 ou 48 explicitamente (em vez de deixá-lo como “automático”).

• Problema 118097 resolvido: um utilizador operador ou parceiro ao depurar um VMware SD-WAN Gateway pode descobrir que o comando debug.py --path não devolve nenhum resultado.

  O problema é causado por uma chave não processada quando um túnel transitório está presente, o que interrompe o comando debug.py --path enquanto o Gateway está a processar os caminhos transitórios.

• Problema 118348 resolvido: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade melhorada, se um utilizador ativar o DHCP numa subinterface VMware SD-WAN Edge, o Edge HA poderá registar uma falha no Serviço dataplane, gerar um núcleo e ser reiniciado para recuperar.

  Se tal ocorrer no Edge ativo, será acionada uma recuperação automática HA e será promovido o Edge em standby. Se tal ocorrer no Edge em standby, não haverá nenhuma recuperação automática, mas o tráfego que utiliza as ligações WAN do Edge em standby será interrompido por um breve período.

• Problema 118436 resolvido: o tráfego DNS para um servidor DNS underlay pode não funcionar.

  O problema pode ocorrer quando a interface routed de um VMware SD-WAN Edge é configurada sem um Gateway e o DHCPv6 com interface IPv6 como um endereço IP do servidor DNS, mas sem um caminho predefinido IPv6 num Gateway de parceiro. Nesta configuração, a resposta DNS do underlay será descartada pelo Edge.

• Problema 118591 resolvido: no site de um cliente que utiliza uma topologia de alta disponibilidade melhorada, o Edge HA em standby pode sofrer flaps de interface frequentes.

  Numa implementação HA melhorada, quando um número elevado de fluxos é enviado ou um número elevado de caminhos está instalado, o estado da interface WAN do Edge em standby passará de ATIVO (UP) a INATIVO (DOWN) e, em seguida, novamente ATIVO (UP).

• Problema 119010 resolvido: nos modelos VMware SD-WAN Edge 520 e 540, o Edge pode não encaminhar o tráfego de uma VLAN localizada nas portas LAN 1-4 para uma VLAN localizada nas portas LAN 5-8 e vice-versa.

  Os modelos Edge 520 e 540 têm duas placas NIC LAN, cada uma com um banco de quatro portas num total de 8 portas LAN. Quando uma LAN é configurada para uma porta LAN no primeiro banco de portas e uma VLAN diferente é configurada para uma porta LAN no segundo banco de portas, o Edge não processa este tráfego corretamente e é descartado.

• Problema 119033 resolvido: durante o arranque, o VMware SD-WAN Gateway pode registar uma falha no Serviço dataplane e ter de ser reiniciado novamente para recuperar.

  Os detalhes das alocações de portas NAT são armazenados intencionalmente num segmento de memória partilhada fora do processo do serviço Gateway (gerido pelo processo NAD). Isto é feito para garantir que o serviço Gateway consegue reiniciar rapidamente a respetiva tabela NAT quando o processo for reiniciado. No entanto, é possível que esse estado persistente fique corrompido, fazendo com que o serviço Gateway falhe imediatamente após o reinício.

  Num Gateway sem uma correção para este problema, remover a tabela NAT ou reiniciar o SO pode impedir que este problema ocorra.

• Problema 119466 resolvido: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade, o tráfego correspondente a uma regra NAT Muitos:1 pode falhar após uma recuperação automática HA.

  Quando este problema é encontrado, as entradas NAT do lado da LAN não são sincronizadas com a Edge em standby. Como o NAT Muitos:1 também envolve PAT (Port Address Translation), as entradas NAT do lado da LAN não podem ser criadas com base na configuração e têm de ser sincronizadas para evitar a interrupção do tráfego numa recuperação automática HA.

• Problema 119544 resolvido: quando a resposta de eco ICMP é desativada na interface de retorno de um VMware SD-WAN Edge, a Verificação de estado de funcionamento de L7 falhará, fazendo com que o Edge acione uma desinstalação de um túnel CSS onde a Verificação de estado de funcionamento de L7 está configurada.

  Além disso, quando o tráfego de gestão é direto, a comunicação entre o Edge e o Orchestrator também é perdida.

  Quando o Edge tenta enviar um pedido de verificação de estado de funcionamento de L7 (pacote SYN HTTP), acederá à interface de retorno, dado que a resposta de eco ICMP está desligada, o que resulta em pacotes HTTP eliminados. Quando a verificação de estado de funcionamento de L7 não obtém um ACK para o pacote SYN que enviou, a verificação de estado de funcionamento de L7 falhará e levará a uma desinstalação do túnel CSS.

  Da mesma forma, quando o Edge tenta enviar pacotes HTTPS para o Orchestrator, chegará à interface de retorno e, como a resposta de eco ICMP está desativada, resultará na eliminação de pacotes HTTPS ACK.

• Problema 119811 resolvido: um cliente pode observar que, na Lista de eventos, há vários eventos do Edge MGD_WEBSOCKET_INIT e MGD_WEBSOCKET_CLOSE por dia.

  Podem existir vários eventos MGD_WEBSOCKET_INIT e MGD_WEBSOCKET_CLOSE apresentados na lista de eventos do Orchestrator sem nenhuma ação do cliente.

  Estas mensagens de evento são falsas e podem ser ignoradas com segurança, uma vez que têm um nível de gravidade “Informativo”.

• Problema 120940 resolvido: se existirem vários caminhos para o mesmo prefixo no BGP de vizinhos diferentes no mesmo VRF interno (como um VRF criado para sessões BGP de Destinos Não-SD-WAN via Gateway), o mesmo IP de vizinho será atualizado para todos os caminhos.

  O problema pode ser observado no SD-WAN Gateway que utiliza os comandos debug.py --routes e debug.py --bgp_view saídas e é causado por um processo de routing de um Gateway que não atualiza o IP de vizinho (origem) corretamente.

• Problema 121024 resolvido: o tráfego do Serviço de acesso remoto (RAS) falha quando uma política empresarial correspondente ao tráfego da Internet é configurada num VMware SD-WAN Edge.

  Quando uma política empresarial correspondente ao tráfego da Internet é configurada num Edge e a ação consiste em enviar este tráfego diretamente, para qualquer tráfego do Serviço de acesso remoto que aceda a este Edge, o tráfego de retorno corresponde a esta política empresarial e é rejeitado no Edge.

  A única solução é configurar uma política empresarial mais específica que corresponda às sub-redes RAS e definir a ação para a enviar através de multicaminhos (através do Gateway).

• Problema 121338 resolvido: num site em que uma ligação WAN está configurada para ser uma reserva dinâmica, o VMware SD-WAN Edge inclui essa ligação como parte da largura de banda disponível.

  Uma ligação WAN de reserva dinâmica está, por predefinição, inativa e não deverá ser incluída na largura de banda disponível de um Edge. Como a reserva dinâmica está incluída, o Edge faz cálculos imprecisos para a largura de banda total disponível e pode resultar na perda de pacotes.

• Problema 121513 resolvido: na empresa de um cliente que utiliza um Gateway de parceiro em que esse Gateway tem a opção “Caminhos BGP seguros” (Secure BGP Routes) ativada, os utilizadores clientes podem registar problemas de qualidade do tráfego.

  O tráfego pode ser descartado nos Edges quando é iniciado com um endereço IP par do BGP como Origem atrás de um Gateway de parceiro quando os Caminhos BGP seguros (Secure BGP Routes) são configurados. Tal deve-se ao facto de, quando o tráfego é iniciado a partir de um ponto final BGP como Origem, criar um fluxo não seguro na Gateway, porque o caminho de origem será do tipo BGP-Peer, para o qual não é efetuado um tratamento seguro das definições. No entanto, se a pesquisa de caminhos de origem nos Edges devolver um caminho seguro, haverá uma incompatibilidade na configuração segura do tráfego de entrada e da pesquisa de caminhos. Tal resultará numa falha na pesquisa dos caminhos de origem nos Edges.

• Problema 121606 resolvido: os clientes ligados a um Gateway de parceiro podem verificar que os túneis VPN IPsec estão inativos no Gateway de parceiro.

  O processo IPsec do Gateway oferece suporte a um máximo de 64 endereços IP numa interface. Para este problema num Gateway de parceiro, os endereços IP de handoff estão a ser adicionados à interface de processo IPsec do Gateway incondicionalmente. Se o número de endereços IP de handoff exceder o limite de 64, os endereços IP mais antigos serão substituídos no processo IPsec, o que fará com que os túneis que utilizam esses IPs fiquem inativos.

  Quando este problema ocorre num Gateway sem uma correção para este problema, não há nenhuma solução alternativa real, assumindo que todos os endereços IP de handoff do PG estão configurados conforme esperado. Caso contrário, a remoção dos IPs de handoff do PG desnecessários poderá ajudar se reduzir os IPs no processo IPsec do Gateway para menos de 64. Será necessário reiniciar o serviço Gateway após essa alteração da configuração.

  Além disso, a alternativa real é mover um número de túneis IPsec para um segundo Gateway de parceiro suficiente para reduzir o número total de handoffs abaixo de 64 no PG afetado.

• Problema 121815 resolvido: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade e que utiliza VNFs, quando um Edge em standby tem uma interface LAN ativa e uma VNF desativada e o Edge ativo tem uma interface LAN inativa e uma VNF ativada, não há nenhuma recuperação automática HA mesmo que o Edge em standby tenha uma porta LAN ativada.

  Este problema resulta do facto de o Edge incluir o estado VNF como parte da contagem LAN no heartbeat HA. Uma VNF ativa contará como uma LAN adicional e resultará nos sintomas indicados.

  O problema é resolvido ao desacoplar os estados VNF da contagem LAN para que as decisões de recuperação automática HA possam ser tomadas corretamente. Com esta mudança, o Edge dá maior prioridade a uma VNF quando tem a conetividade WAN e LAN básica ativada. Por outras palavras, se o Edge ativo tiver uma VNF inativa e o Edge em standby tiver uma VNF ativa, o Edge em standby será promovido a ativo se tiver pelo menos 1 WAN e 1 LAN, independentemente da contagem LAN/WAN no Edge ativo.

• Problema 121998 resolvido: no caso de um cliente que utiliza a firewall com estado numa topologia Hub/Spoke, o tráfego que corresponde a uma regra de firewall configurada para o tráfego Spoke para Hub, em que a regra inclui uma VLAN de origem, poderá ser descartado.

  Quando há uma alteração na versão da classificação da aplicação, da tabela da política empresarial ou da tabela de política de firewall, o SD-WAN executa uma pesquisa de fluxos na firewall no seu próximo pacote. Devido a um problema de temporização, esse pacote pode ser um do lado do tráfego de gestão (VCMP). Como resultado, durante a criação de uma chave de pesquisa de política de firewall, o SD-WAN troca a VLAN do Spoke Edge pela VLAN do Hub Edge, o que causa a falta de correspondência com a regra e ao descarte do tráfego.

  Num Edge sem uma correção para este problema, o cliente pode alterar a Origem (Source) de uma VLAN do Edge para “Qualquer” (Any).

• Problema 122029 resolvido: um Serviço de Segurança na Cloud (normalmente, Zscaler) implementado com a automatização GRE em que o VMware SD-WAN Edge utiliza uma versão 5.2.x não funciona.

  Este problema é causado pelo facto de o endereço IP local e os endereços IP públicos não serem enviados, mas estas informações serem necessárias para que o Orchestrator envie um estado da configuração do túnel inativo para o Edge. O túnel tem de estar num estado pendente para que o Orchestrator envie a configuração GRE automatizada.

  Este problema é limitado aos Edges 5.2.x. O utilizador só poderá contornar este problema se mudar para uma versão anterior do Edge, versão 5.1.x ou anterior, ativar o túnel e, em seguida, atualizar para a versão 5.2 ou superior.

• Problema 122528 resolvido: na empresa de um cliente que utiliza caminhos estáticos WAN com pesquisas ICMP configuradas, as pesquisas ICMP podem deixar de funcionar em vários VMware SD-WAN Edges de uma só vez com todo o tráfego que utiliza esses caminhos a diminuir.

  Cada Edge tem um contador de sequência de pesquisa ICMP com um número máximo de 65 535 iterações. Quando este contador ultrapassa as 65 535 iterações, as pesquisas falham.

  Num Edge sem uma correção para este problema, a solução será remover a pesquisa ICMP, reiniciar o serviço Edge e, em seguida, restaurar a pesquisa.

• Problema 123144 resolvido: na página Monitorizar > Edge > Destinos (Monitor > Edge > Destinations) da IU do Orchestrator, a página mostra nomes de domínio de destino inválidos.

  O Edge envia nomes de destino inválidos, como IP:port, que são mostrados na IU do Orchestrator devido a uma falha de validação nos nomes de anfitrião DNS.

• Problema 123237 resolvido: no caso de um VMware SD-WAN Edge a executar a versão 5.2.x e nos casos em que as interfaces são configuradas apenas com IPv6, a página Diagnóstico > Diagnóstico remoto (Diagnostics > Remote Diagnostics) não é carregada.

  Quando apenas as interfaces Edge IPv6 são configuradas com definições de IPv4 desativadas, é lançada uma exceção num script-chave que faz com que a página Diagnóstico > Diagnóstico remoto (Diagnostics > Remote Diagnostics) não seja carregada.

  A solução alternativa será ativar as definições de IPv4 com a configuração fictícia.

• Problema 123956 resolvido: um utilizador não consegue aceder à IU local num VMware SD-WAN Edge com uma versão 5.2.x.

  A página do browser não carrega com um erro 404. O problema resulta das exceções apresentadas nos scripts do Diagnóstico remoto e da IU local.

• Problema 124106 resolvido: quando a NAT do lado da LAN é configurada para traduções Muitas:1, quando a Port Address Translation (PAT) é utilizada, o tráfego iniciado na direção oposta permite o acesso inesperado a endereços fixos com base na máscara externa e no endereço IP original.

  As regras NAT do lado de LAN permitem que as ligações sejam iniciadas em ambas as direções para as regras Muitos:1 sem uma forma clara de impedir o tráfego na direção 1:Muitos. Agora, as traduções 1:Muitos serão bloqueadas e os utilizadores devem criar regras NAT 1:1 explícitas para ativar o tráfego.

  Esta questão é totalmente abordada na secção Notas Importantes: Alteração do comportamento da NAT do lado da LAN

• Problema 124162 resolvido: quando um utilizador faz uma captura de pacotes numa interface VMware SD-WAN Edge, pode ver um pacote que parece estar corrompido.

  Não há corrupção real do pacote, o pacote só aparece corrompido no ficheiro PCAP. Este problema deve-se a um defeito na forma como o Edge grava os pacotes na interface de captura de pacotes. Os pacotes marcados com VLAN podem ser gravados incorretamente e aparecerão como um pacote corrompido (tipo ether inválido) no ficheiro PCAP.

• Problema 124263 resolvido: um cliente pode observar uma elevada utilização da CPU num VMware SD-WAN Edge ao processar pacotes de descoberta de vizinhos IPv6 (ND) e de encapsulamento L2.

  A resolução de problemas do Edge aponta para api - vc_ip6_host_addr_to_network_addr como estando a consumir muita CPU.

• Problema 124357 resolvido: um VMware SD-WAN Edge pode registar uma falha no Serviço dataplane e, como resultado, ser reiniciado.

  Quando uma política empresarial é configurada com backhaul de Internet e um byte de 3000 ou superior é enviado do lado da LAN, o processo Edge afirma que os pacotes de grandes dimensões provocam uma falha no serviço.

• Problema 125035 resolvido: quando um cliente implementa uma VNF Fortinet 6.4.x, o endereço IP de gestão de Edges não fica acessível.

  A Fortinet fez alterações na versão 6.4.x, o que faz com que o FortiLink e o modo transparente não funcionem juntos. O SD-WAN não utiliza o FortiLink e, como resultado, a resolução para este problema é desativar o FortiLink antes de definir o modo transparente durante a implementação da VNF.

• Problema 125421 resolvido: os clientes podem observar que as ligações WAN de um VMware SD-WAN Edge são apresentadas de forma intermitente como inativas e depois ativas na página Monitorização e eventos (Monitoring and Events) da IU do VMware SASE Orchestrator, com a possibilidade de o Edge deixar de responder e não conseguir passar o tráfego até ser reiniciado manualmente. O Edge pode ainda registar uma falha no Serviço dataplane e ser reiniciado.

  Este é um problema de fuga de memória do Edge, registado quando o Serviço dataplane do Edge não consegue abrir a memória partilhada o que pode levar a PIs obsoletos. Isto, por sua vez, provoca o esgotamento dos descritores de ficheiros abertos, o que afetará inicialmente as ligações WAN. No entanto, se este problema for suficientemente avançado e resultar no esgotamento da memória do Edge, o Edge poderá:

  1. Deixar de responder e ficar inacessível através do Orchestrator, o que exige um reinício/ciclo de energia no local.

  2. Acionar uma falha do serviço do Edge com a geração de um ficheiro principal e com o Edge a reiniciar para recuperar.

• Problema 125487 resolvido: o fluxo de tráfego de Edge a Edge pode ser interrompido por um problema de resolução ARP.

  Quando este problema ocorre, o Edge está a encaminhar o pedido ARP para o endereço IP de próximo hop através do endereço IP da interface principal em vez do endereço IP da subinterface. O problema é acionado durante a criação do fluxo quando um caminho não ligado é utilizado para chegar ao destino e, se a subinterface do Edge for utilizada para essa conetividade, o Edge não preencherá corretamente o endereço IP de origem para o caso da subinterface.

• Problema 126304 resolvido: as regras NAT 1:1 cuja tradução de origem se sobrepõe às regras NAT Muitos:1 ou a outras regras NAT 1:1 podem dar origem a colisões de portas ou a falhas nas traduções.

  Para corrigir este comportamento, quando a tradução de origem de uma regra NAT 1:1 se sobrepõe a outra regra, a PAT (Port Address Translation) também é ativada para a regra NAT 1:1.

• Problema 126458 resolvido: no site de um cliente implementado com uma topologia de alta disponibilidade em que os Edges HA são modelos Edge 520/540, o cliente pode observar várias recuperações automáticas HA, resultantes de um estado Ativo/Ativo.

  A condição é acionada em Edges 520/540 configurados com HA, quando o número de fluxos simultâneos excede os 300 mil.

  Nos Edges HA 520/540 sem uma correção para este problema, a solução alternativa passa por aumentar o tempo da recuperação automática HA de 700 ms para 7000 ms na página Configurar > Edge > Dispositivo (Configure > Edge > Device), pois isso reduzirá a alteração de um estado Ativo/Ativo.

• Problema 127127 resolvido: um VMware SD-WAN Edge não memoriza os caminhos dos Hub Edges quando os VMware SD-WAN Gateways são atualizados para a versão 5.1.x ou superior.

  Quando um Edge é configurado com Ramo a ramo através dos Hubs com apenas o mesmo Edge na lista e o Gateway está a executar a versão 5.1.x e superior, os caminhos não serão anunciados do Gateway para o Edge.

  A única solução alternativa é remover o Edge da configuração Ramo a ramo através dos Hubs.

• Problema 127403 resolvido: na página Teste e resolução de problemas > Diagnóstico remoto (Test & Troubleshoot > Remote Diagnostics) da IU do Orchestrator, ao executar o diagnóstico remoto Resolução de problemas OSPF – Listar caminhos redistribuídos OSPF (Troubleshoot OSPF – List OSPF Redistributed Routes) ou Resolução de problemas BGP – Listar caminhos redistribuídos BGP (Troubleshoot BGP – List BGP Redistributed Routes), o teste devolve um erro sem dados.

  Depois de executar qualquer um dos diagnósticos, o utilizador observa um erro: Erro ao ler dados do teste (Error reading data for test).

• Problema 128377 resolvido: na empresa de um cliente que utiliza o BGP para routing, o cliente pode observar que o tráfego do utilizador é interrompido devido a uma falha do BGP.

  O processo BGP pode falhar durante a limpeza devido ao acesso inválido à memória de self_mac_hash.

  Como parte da limpeza do bgp_master, o self_mac_hash já está limpo. No entanto, ao processar a mensagem após a limpeza ter ocorrido, o BGP acede ao hash eliminado que causa a falha.

• Problema 128741 resolvido: um VMware SD-WAN Gateway pode sofrer uma falha do Serviço dataplane, gerar um ficheiro principal e reiniciar para recuperar.

  Quando um pacote de gestão válido chega inesperadamente a um túnel IPsec do Destino Não-SD-WAN ou a uma interface GENEVE, o Gateway pode deparar-se com um erro durante o processamento desse pacote, o que faz com que o processo do serviço Gateway falhe.

Problemas resolvidos do Orchestrator

• Resolvido na versão R5401-20231115-GA do Orchestrator
• Resolvido na versão R5400-20231020-GA do Orchestrator

Resolvido na versão R5401-20231115-GA do Orchestrator

A compilação R5401-20231115-GA do Orchestrator foi lançada a 15/11/2023 e é a primeira compilação rollup do Orchestrator para a versão 5.4.0.

Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde a compilação GA R5400-20231020-GA original.

• Problema 117138 resolvido: ao utilizar a automatização do Zscaler para criar um Serviço de Segurança na Cloud (CSS) Zscaler, os túneis IPsec CSS de Edge para Zscaler podem não ser criados.

  O Orchestrator garante a colocação em fila de apenas uma ação por Edge. No entanto, se uma ação estiver bloqueada no estado NOTIFICADO (NOTIFIED), todas as ações subsequentes não serão executadas e os túneis IPsec não serão criados.

  Num Orchestrator sem uma correção para este problema, o utilizador operador terá de eliminar manualmente a ação obsoleta do Edge da base de dados do Orchestrator.

• Problema 123078 resolvido: ao utilizar a IU do VMware SASE Orchestrator e navegar para a página Monitorizar > Edge > Visão geral (Monitor > Edge > Overview), as colunas não estão alinhadas corretamente e são difíceis de ler.

  A IU não inclui nenhuma informação para a coluna Número de série do dispositivo (Device Serial Number), o que significa que há 11 colunas, mas apenas 10 cabeçalhos e isso causa o problema de legibilidade.

• Problema 123387 resolvido: Um utilizador não pode adicionar um Destino Não-SD-WAN (NSD) via Gateway do Zscaler com um endereço IP existente.

  A validação do Orchestrator impede que os utilizadores adicionem um Zscaler com um endereço IP principal ou secundário que já seja utilizado noutro NSD via Gateway.

• Problema 125309 resolvido: quando um utilizador desativa o IPv6 ao nível do Edge em Configurar > Dispositivo > Definições de IPv6 (Configure > Device > IPv6 Settings), continua a ser possível editar, ativar e guardar a opção OSPF para IPv6.

  Isto causa confusão ao utilizador cliente que configura essas definições sem saber que não o deve fazer porque a versão IPv6 do OSPF não está em vigor.

• Problema 125964 resolvido: no caso de um cliente que implementa Destinos Não-SD-WAN (NSD) via Gateway, ao navegar para a página Configurar (Configure) > Serviços de rede (Network Services) > NSD via Gateway > IKEv2 genérico (Generic IKEv2) e clicar em Guardar (Save) após adicionar sub-redes do site personalizadas, as alterações à configuração NSD não estão a ser guardadas.

  Este problema deve-se a campos inválidos Tempo de vida IKE SA (min) e Tempo de vida IPsec SA (min) [IKE SA Lifetime(min) and IPsec SA Lifetime(min)] na seção Gateway VPN principal (Primary VPN Gateway).

  O cliente está a utilizar a IU antiga para concluir a tarefa.

• Problema 126602 resolvido: um cliente não consegue adicionar um conjunto de gateways ao respetivo conjunto de gateways na configuração de parceiro existente.

  A tentativa de o fazer devolverá um erro se o conjunto de gateways na configuração de parceiro tiver um conjunto gerido, dado que os IDs do conjunto geridos existentes não são removidos pela IU.

• Problema 127727 resolvido: ao criar um novo Serviço de Segurança na Cloud (CSS), um utilizador não consegue configurar a opção Preferência doméstica (Domestic Preference).

  Se um utilizador ativar a caixa de seleção Preferência doméstica (Domestic Preference) e guardar a configuração, o Orchestrator verificará as credenciais e apresentará uma mensagem a informar “Alterações guardadas com sucesso!” (Changes saved successfully!). Mas, depois de guardar, quando o perfil CSS é aberto novamente, o utilizador observará que a caixa de seleção Preferência doméstica (Domestic Preference) não está selecionada.

• Problema 127774 resolvido: em Configurar > Edge > Dispositivo > Conetividade > Interfaces de retorno (Configure > Edge > Device > Connectivity > Loopback Interfaces), as tentativas de um utilizador configurar uma interface de retorno podem não ser bem-sucedidas.

  Quando este problema ocorre, o utilizador configura uma interface de retorno para um Edge e guarda as alterações, a IU não gera nenhum erro, mas a configuração não é aplicada e não é apresentada na página da IU.

• Problema 127843 resolvido: a IU não é apresentada corretamente quando localizada para o idioma italiano.

  Isto afeta o utilizador porque alguns separadores de navegação se sobrepõem uns aos outros.

• Problema 128017 resolvido: um cliente pode observar que, ao navegar para a página Configurar > Edge > Dispositivo (Configure > Edge > Device), a página nunca é carregada.

  Quando este problema ocorre, as referências de configuração do Edge são eliminadas por engano pelo Orchestrator da respetiva base de dados. Quando estas referências são removidas, não será possível restaurá-las.

  Num Orchestrator sem uma correção para este problema, a única solução é forçar o Edge a utilizar todas as configurações do perfil associado a esse Edge. Se o Edge tiver muitas configurações personalizadas de sobreposição do Edge, isso significará criar um perfil especial apenas para esse Edge.

• Problema 128277 resolvido: Quando um utilizador parceiro ou de empresa nativo (aquele que inicia sessão no Orchestrator com um nome de utilizador e palavra-passe) tenta iniciar sessão com uma palavra-passe expirada, a IU entra num ciclo e apresenta um ecrã em branco.

  O utilizador verá o ecrã Palavra-passe expirada (Expired Password) a ser atualizado indefinidamente. A única forma de contornar este problema passa por um operador ou parceiro com a função correta redefinir a palavra-passe do utilizador.

• Problema 127904 resolvido: quando um utilizador cria um caminho estático e adiciona uma pesquisa ICMP a este caminho, o Edge não instala a pesquisa ICMP e apresenta um erro de análise.

  Este problema deve-se ao envio do valor do IP de origem e do IP de próximo hop como nulo em vez de uma cadeia vazia a partir do Orchestrator para o Edge.

• Problema 128279 resolvido: na página Configurar (Configure) > Controlo de fluxo de overlay (Overlay Flow Control) > Lista de rotas (Routes List), o utilizador pode ver um máximo de 256 caminhos sem nenhuma opção para clicar numa página de caminhos adicional.

  O limite fixo de 256 caminhos e a falta de paginação afeta os clientes com empresas de grande dimensão, que incluem um número de caminhos muito superior ao limite fixo de 256.

• Problema 128357 resolvido: na empresa de um cliente que utiliza OSPFv2 ou OSPFv3 para routing, se for selecionado OE1 na lista Caminho predefinido (Default Route), é apresenta uma opção inválida “Nenhum” (None) na lista Anunciar (Advertise).

  As opções válidas para Anunciar (Advertise) são “Sempre” (Always) e “Condicional” (Conditional). Nenhum (None) não é uma opção válida e não deve aparecer na IU.

• Problema 128765 resolvido: na página Filtros BGP (BGP Filters), o botão Enviar (Submit) pode manter-se inacessível quando um utilizador altera as páginas.

  Quando um utilizador edita a tabela Filtros BGP (BGP Filters) e navega para outra página com um estado inválido numa página atual, os controlos serão inválidos depois de regressar e o utilizador preencher as informações corretas.

  Num Orchestrator sem uma correção para este problema, o utilizador terá de permanecer na página da tabela onde o controlo é inválido. Como alternativa, o utilizador pode remover essa linha e adicioná-la novamente.

• Problema 129061 resolvido: no caso de um cliente com a opção Handoff de parceiro (Partner Hand off) ativada no ecrã Cliente (Customer) > Definições globais (Global Settings) > Configuração do cliente (Customer Configuration) > Configuração adicional (Additional Configuration) > Conjunto de gateways (Gateway Pool), não é possível clicar nas caixas de verificação “Utilização para túneis privados” (Use for Private Tunnels) e “Anunciar endereço IP local via BGP” (Advertise Local IP Address via BGP) na secção IPv6 da Interface de handoff (Hand Off Interface) do Gateway.

  Isto impede que o utilizador desative o túnel privado IPv6 para a interface de handoff. 

• Problema 129494 resolvido: na página Cliente > Definições globais > Configuração do cliente > Configuração do serviço > SD-WAN (Customer > Global Settings > Customer Configuration > Service Configuration > SD-WAN), quando um utilizador está a editar a configuração do serviço, é necessário adicionar o nome de domínio sempre.

  O utilizador tem de fazer isto mesmo que a autenticação de Início de sessão único (SSO) ou o serviço Edge Network Intelligence (ENI) não esteja configurado para o cliente. Um nome de domínio não será obrigatório se um cliente não estiver a utilizar o ENI ou o SSO.

• Problema 129584 resolvido: na página Configurar > Edges > Política empresarial (Configure > Edges > Business Policy), quando um utilizador edita uma regra de política empresarial existente, a IU do Orchestrator não atualiza o valor reconfigurado para o campo Destino (Destination) mesmo depois de guardar as alterações.

  Por exemplo, para uma regra de política empresarial existente com Destino (Destination) definido como “Endereço IP” (IP Address), se o utilizador alterar o valor de Destino (Destination) para “Qualquer” (Any) e guardar a alteração, as alterações feitas no campo Destino (Destination) da regra não serão refletidas na IU. O utilizador continuará a ver o campo Destino (Destination) definido como “Endereço IP” (IP Address) em vez de “Qualquer” (Any) na regra.

• Problema 129756 resolvido: quando um operador executa o esquema de atualização num VMware SASE Orchestrator baseado na cloud, o Orchestrator pode não conseguir estabelecer ligação à base de dados remota.

  Este problema não afeta os Orchestrators baseados em VMs.

• Problema 129765 resolvido: ao editar uma interface routed para um VMware SD-WAN Edge, a IU do Orchestrator preenche um valor predefinido incorreto para dhcpServer.options.

  Por exemplo, quando um utilizador edita a interface routed “GE3” e guarda os dados de configuração das definições do dispositivo, o valor do campo “options” em “dhcpServer” é enviado como nulo em vez de uma matriz vazia.

• Problema 129894 resolvido: no portal do operador da IU do Orchestrator, ao consultar o ecrã Gestão de Gateways (Gateway Management) > Gateways > Visão geral (Overview) > Utilização do cliente (Customer Usage), o utilizador pode observar que alguns detalhes do túnel do cliente do Edge estão em falta.

  Este problema poderá ocorrer se o nome do Edge, o nome do conjunto de gateways e o tipo de gateway forem os mesmos.

• Problema 130153 resolvido: no caso de utilizadores empresariais com uma função de suporte, a opção Reiniciar o serviço (Restart Service) não está disponível no menu Monitorizar > Edges > Selecionar Edge > Atalhos > Ações remotas (Monitor > Edges > Select Edge > Shortcuts > Remote Actions).

  Isto impede que os utilizadores com função de suporte reiniciem o serviço Edge no menu Atalhos (Shortcuts) da página Monitorizar > Edges (Monitor > Edges).

• Problema 130877 resolvido: Quando um utilizador adiciona um caminho estático a um Edge através da IU do Orchestrator, os utilizadores cliente desse Edge podem observar que o tráfego falha para alguns caminhos locais.

  Na IU, em Configurar > Edge > Dispositivo > Routing e NAT > Definições de caminho estático (Configure > Edge > Device > Routing & NAT > Static Route Settings), as definições de interface para os Caminhos locais (Local Routes) são alteradas para N/D (N/A) e não podem ser editadas. Os registos local_routes desse Edge mostrarão "reachable": "False" para os caminhos locais afetados.

  Este problema pode ocorrer quando o IP de próximo hop de um caminho estático está dentro da mesma sub-rede da rede VLAN. Neste cenário, a IU do Orchestrator remove a interface do caminho estático, o que faz com que esses caminhos locais apresentem uma acessibilidade falsa.

• Problema 131846 resolvido: na página Definições globais > Configuração do cliente > Handoff de parceiro > Interface de handoff (Global Settings > Customer Configuration > Partner Hand off > Hand Off Interface) da IU do Orchestrator, quando um utilizador clica no botão Adicionar (Add) para adicionar um caminho estático, a IU devolve uma mensagem de erro..

  Quando o utilizador clica no botão Adicionar (Add) na secção de caminhos estáticos, é adicionada uma nova linha vazia à tabela, mas é apresentada uma mensagem de erro a indicar “Não é possível guardar as alterações. Há um ou mais erros na configuração” (Cannot save changes. There is one or more errors within your configuration). Este erro é causado por uma validação em falta na configuração de caminho estático vazio na secção Handoff de parceiro (Partner Handoff) do ecrã Definições globais (Global Settings). Este problema afeta apenas linhas onde não está configurada nenhuma informação.

  Há duas soluções alternativas para este problema:

  • Preencher todos os campos obrigatórios. Ao fazer isso, a mensagem de erro (“Não é possível guardar as alterações...” (Cannot save changes...)) será resolvida automaticamente.

  • Remover todas as linhas vazias recém-adicionadas da secção. Depois de remover estas linhas vazias, a mensagem de erro será resolvida automaticamente.

Resolvido na versão R5400-20231020-GA do Orchestrator

A versão R5400-20231020-GA do Orchestrator foi lançada a 23/10/2023 e resolve os seguintes problemas desde a versão R5302-20231011-GA do Orchestrator.

A versão 5.4.0 contém todas as correções do Orchestrator que estão listadas nas Notas de versão 5.2.0 até à versão 5.2.0.3 (R5203-20230809-GA) e todas as correções do Orchestrator nas Notas de versão 5.3.0 até à versão 5.3.0.2 (R5302-20231011-GA).

• Problema 48230 resolvido: na página Monitorizar > Edges (Monitor > Edges), a procura de Edges por “Modelo” (Model) não é totalmente precisa.

  Quando um utilizador filtra pelo número do modelo, o Orchestrator devolve Edges adicionais.

• Problema 48609 resolvido: na página Monitorizar > Routing (Monitor > Routing), o utilizador não consegue classificar o nome do segmento numa tabela de caminhos multicast.

  Na versão 5.4.0, a API é melhorada para aceitar o nome do segmento como um parâmetro de classificação e ajuda na classificação do nome do segmento.

• Problema 78581 resolvido: um utilizador pode anunciar uma VLAN quando os caminhos ligados estão desativados na IU do Orchestrator.

  Esta ação deve ser rejeitada pelo Orchestrator com a apresentação de um erro. Na versão corrigida, a IU do Orchestrator escuta os caminhos ligados e desativa o sinalizador de anúncio com base nos caminhos ligados e vice-versa.

• Problema 82095 resolvido: o utilizador pode configurar definições do dispositivo inválidas para VLANs do Edge que resultarão em problemas significativos de conetividade para o Edge.

  O Orchestrator não está a tentar validar as configurações do dispositivo. Em particular, uma configuração de VLAN para uma porta switched com uma tabela vazia. Algumas configurações podem ter tantos erros que o processo de gestão de Edges falhará.

  Num Orchestrator sem uma correção para este problema, o cliente deve analisar todas as definições do dispositivo VLAN e garantir que estão válidas, uma vez que o Orchestrator não está a fazer a verificação.

• Problema 91869 resolvido: quando um utilizador operador acede a Gerir parceiros (Manage Partners) e clica no botão “Adicionar perfil do operador” (Add Operator Profile), a descrição do perfil do operador aparece truncada quando excede um determinado comprimento de texto.

  O Orchestrator não deve truncar a descrição do perfil do operador, independentemente do comprimento do texto.

• Problema 92766 resolvido: na página Monitorizar > Routing (Monitor > Routing), as informações de paginação estão incorretas.

  Se um utilizador clicar no botão Seguinte (Next), a página da IU não parará mesmo depois de chegar à última página devido à aplicação incorreta da lógica de filtragem, o que faz com que o número de página apresentado não esteja correto.

• Problema 102121 resolvido: quando a configuração do Secure Access de um Edge é atualizada várias vezes sem atualizações na configuração da firewall do Edge ao utilizar a IU do Orchestrator, as atualizações da configuração do Secure Access podem deixar de ser enviadas aos Edges.

  O problema tem ocorrido com mais frequência em testes em que a Equipa de Engenharia força deliberadamente um grande número de atualizações do Secure Access sem atualizações de firewall. No entanto, em casos raros, pode ser acionado pelo cliente em ambiente real.

  Se este problema ocorrer num Orchestrator sem uma correção, o utilizador poderá atualizar manualmente a configuração da firewall do Edge na IU apenas uma vez. Após a atualização manual da firewall, o utilizador pode refazer a alteração da configuração do Secure Access do Edge na IU e o Orchestrator enviará a alteração da configuração do Secure Access do Edge na IU para os Edges.

• Problema 103828 resolvido: o filtro de pesquisa de aplicações do Editor de mapa de aplicação tem pouca clareza.

  Isto torna a verificação ou alteração da configuração de uma aplicação muito difícil, exigindo paginação manual através de várias páginas de aplicações para encontrar a aplicação de interesse.

• Problema 104395 resolvido: a seção “Ligações inativas” (Links Down) da página Monitorizar > Rede > Visão geral (Monitor > Network > Overview) mostra apenas os primeiros 10 sites com ligações inativas. Quando um utilizador clica no botão “Ver tudo” (View All), a IU do Orchestrator leva-o para a secção Edges, que apresenta uma lista de todos os Edges, independentemente do estado da ligação, mesmo que o utilizador só queira ver sites com Edges que tenham uma ou mais ligações inativas.

  Quando um utilizador clica no ícone “Ligações inativas” (Links Down), a lista deve mostrar todas as ligações inativas, não apenas 10, e não há a possibilidade de filtrar Edges por estado de ligação ou de Edge depois de se clicar no botão “Mostrar tudo” (Show All).

• Problema 108285 resolvido: ao configurar um perfil na IU do Orchestrator, se um utilizador alterar uma interface Edge de switched para routed, o Orchestrator acrescentará a nova interface routed ao final da routed em vez de a inserir no índice adequado.

  A ordem incorreta das interfaces routed numa configuração do perfil causa problemas de validação quando um utilizador adiciona um caminho estático com essas referências para essa interface routed.

• Problema 108687 resolvido: um utilizador pode configurar um Destino Não-SD-WAN via Gateway para ter vários Gateways com o mesmo endereço IP.

  O Orchestrator deve rejeitar esta configuração e apresentar um erro.

• Problema 109125 resolvido: na página Administração > Gestão de utilizadores (Administration > User Management) da IU do Orchestrator, o utilizador não consegue ordenar as Chaves SSH pela coluna Duração (Duration).

  Isto limitará a capacidade de um utilizador encontrar uma chave SSH específica se a tentar localizar pela duração da chave.

• Problema 109715 resolvido: uma ligação WAN inativa desaparece da página Monitorizar > Visão geral da rede (Monitor > Network Overview) após 24 horas, mesmo que o Limite de ligação inativa do Edge (Edge Down Link Limit) esteja definido como um valor superior a 24 horas.

  Um utilizador pode navegar para Clientes e parceiros > Monitorizar clientes > Definições de serviço > Gestão de Edges (Customers & Partners > Monitor Customers > Service Settings > Edge Management) e, na secção Definições gerais do Edge (General Edge Settings), o Limite de ligação inativa do Edge (Edge Link Down Limit) pode ser definido para um valor superior a 24 horas e guardado. No entanto, apesar desta nova definição, uma ligação WAN desativada deixa de estar presente na página Monitorizar (Monitor) após 24 horas.

• Problema 110285 resolvido: um utilizador numa empresa cliente com mais de 5000 Serviços de Rede pode observar que a IU do Orchestrator carrega lentamente para Visão geral da rede, Monitorizar > Edges (Network Overview, Monitor > Edges), Configurar > Edges (Configure > Edges) e Configurar > Edges > Dispositivo (Configure > Edges > Device)

  Este problema é causado pelo facto de a chamada à API getEnterpriseServices demorar muito tempo a obter os resultados quando há um grande número de serviços de rede a recuperar.

• Problema 111407 resolvido: o VMware SASE Orchestrator não permitirá que um utilizador desative a interface routed de um Edge se for definida pelo utilizador e se não tiver nenhuma ligação WAN associada.

   A validação do Orchestrator não permite que um utilizador guarde dados sem uma ligação WAN adicionada e a única solução é adicionar uma ligação WAN.

• Problema 111497 resolvido: na página Configurar > Controlo de fluxo de overlay (Configure > Overlay Flow Control) da IU do Orchestrator, os valores de VPN de saída preferida (Preferred Exit VPN) são mostrados como “indefinidos” (undefined) para sub-redes do site.

  Se a configuração do próximo hop estiver configurada para um Destino Não-SD-WAN via Gateway, as sub-redes do site em Configurar > Controlo de fluxo de overlay (Configure > Overlay Flow Control) mostrarão VPN de saída preferida (Preferred Exit VPN) como “indefinida” (undefined) para as VPNs cujo tipo de túnel é “ATIVO_ATIVO” (ACTIVE_ACTIVE).

• Problema 111778 resolvido: quando um utilizador está a editar um Destino Não-SD-WAN via Gateway com o tipo ponto de verificação, o Orchestrator altera o tipo de VPN para router genérico IKEv1.

  Este problema causa problemas a qualquer cliente com um ponto de verificação do tipo NSD e poderá causar a interrupção se o utilizador não perceber o que a IU do Orchestrator está a fazer.

• Problema 112123 resolvido: quando um VMware SD-WAN Edge 640-N é adicionado, a IU do VMware SASE Orchestrator apresenta o nome do modelo incorretamente.

  A IU do Orchestrator apresenta o nome “EdgeModel.edge640-n” e não “Edge 640-N”.

• Problema 112188 resolvido: na empresa de um cliente que implementa um Destino Não-SD-WAN com GRE, quando o túnel NSD fica inativo, o Orchestrator apresenta uma mensagem incorreta.

  O Orchestrator apresenta a mensagem: “Túnel IPsec direto Edge inativo” (Edge Direct IPsec tunnel down) quando o túnel NSD é GRE.

• Problema 112535 resolvido: ao configurar uma regra de Firewall em Configurar > Firewall (Configure > Firewall), o ecrã Origem > Definir > Transporte (Source > Define > Transport) apresenta a Porta de transporte (Transport Port) incorretamente.

  O Orchestrator apresenta a opção Porta de transporte (Transport Port) como apenas “Transporte” (Transport), o que é vago e pode causar confusão ao configurar uma regra de Firewall.

• Problema 112826 resolvido: quando um cliente exporta uma lista de alertas para um ficheiro CSV através da IU do Orchestrator, são apresentados apenas 512 itens.

  Fazer a mesma exportação com uma API pode permitir apresentar até 2048 alertas, que também é a quantidade esperada para a exportação da IU do Orchestrator. A limitação a 512 afeta os clientes que exportam alertas quando o número de alertas excede o limite de 512 para o período de tempo especificado.

• Problema 113474 resolvido: o utilizador não consegue configurar um endereço da interface anfitrião parcial ao configurar a Delegação de prefixo DHCPv6 em interfaces ou subinterfaces LAN IPv6.

  O Orchestrator não tem validação adequada para permitir um endereço IPv6 parcial.

  O que se espera deste comportamento: com a correção, os seguintes tipos de endereços de interface completos ou parciais são permitidos ou bloqueados para a Delegação de prefixo DHCPv6 em LAN e VLAN:

  • Endereços IPv6 permitidos:

    • 2001::20; 2222:db8:3333:4444:5555:6666:7777:8888

    • 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF

    • ::1:0:0:0:1

    • ::f:1:0:f

    • ::f:1:e;

    • ::c:1

  • UNIQUE_LOCAL_IPV6 - fc00::

  • GLOBAL_UNICAST - 2000:: ou 2001:0DB8:C21A:1::

  • Endereços IPv6 bloqueados:

    • endereço vazio - ::

    • endereço multicast - FF01:0:0:0:0:0:0:18C, FF01:0:0:0:0:0:0:BAC0 ou FF01:0:0:0:0:DB8::

    • retorno - 0:0:0:0:0:0:0:1 ou ::1

    • ligação local - fe80::210:5aff:feaa:20a2 ou fe80::260:97ff:fe02:6ea5

    • site local - fec0::

  • Só é permitido utilizar um par de ::, portanto, os seguintes endereços IP são bloqueados: ::1:0:0::0:1 ou ::f:1:0::f

• Problema 113530 resolvido: o utilizador não consegue alterar o tipo de endereço IPv6 de Delegação de prefixo DHCPv6 para qualquer outro tipo numa interface ou subinterface LAN routed.

  Na secção Configurar > Edge > Dispositivo > Interface > LAN IPv6 (Configure > Edge > Device > Interface > LAN IPv6), em que a Delegação de prefixo DHCPv6 pode ser configurada no Orchestrator, se o utilizador tentar selecionar qualquer outro tipo de endereço (Estático/DHCP com estado/DHCP sem estado), a opção Guardar (Save) permanecerá inacessível e o utilizador não poderá concluir a alteração. O problema é o resultado de um defeito num processo que verifica a exclusividade da configuração da Delegação de prefixo DHCPv6 num Edge.

• Problema 114151 resolvido: ao apresentar Edges e Gateways nas respetivas páginas de listas, o certificado atribuído aos mesmos é uma coluna opcional.

  A utilização de certificados é um comportamento predefinido, portanto, os conjuntos de colunas predefinidos para as listas de Edges ou Gateways devem mostrá-los sempre sem exigir que o utilizador os defina.

• Problema 114444 resolvido: quando um VMware SASE Orchestrator é atualizado para a versão 5.1.x ou superior, o utilizador não consegue guardar as respetivas alterações de uma configuração para um Destino Não-SD-WAN via Gateway onde os túneis redundantes já estão configurados.

  O utilizador não conseguirá guardar a configuração na página NSD via Gateway, o que poderá causar a queda de pacotes em Gateways para NSDs redundantes.

  A solução alternativa para este problema é atualizar o hop máximo para 2 na IU do NSD via Gateway para os vizinhos BGP redundantes e guardar as alterações.

• Problema 114475 resolvido: quando um operador tenta atualizar um VMware SASE Orchestrator da versão 4.2.0 para 5.1.0, o Orchestrator pode comunicar que a atualização falhou.

  Nos registos, o Operador veria esta entrada: Error while initializing CWS Server service Error: Too many connections. Este problema é causado pela reinicialização do MySQL antes da instalação de vco-db-schema, o que se deve ao facto de o MySQL não definir o número máximo de ligações. Além disso, apesar de o Orchestrator comunicar que a instalação falhou, na realidade, a instalação foi concluída e o utilizador pode reiniciar o Orchestrator e todos os serviços funcionarão conforme o esperado.

• Problema 114897 resolvido: quando se tem sessão iniciada na IU do VMware SASE Orchestrator como parceiro ou quando um operador analisa o nível de parceiro, o separador “Clientes” (Customers) é apresentado como “Clientes e parceiros” (Customers & Partners).

  O nome correto é Clientes (Customers) e é apresentado com esta versão do Orchestrator.

• Problema 115441 resolvido: na página Definições globais > Configuração do cliente (Global Settings > Customer Configuration), ao configurar o mosaico SD-WAN, as imagens de software e firmware só ficam visíveis quando são ativadas.

  As imagens de software e firmware devem estar sempre visíveis para o utilizador, independentemente do respetivo estado.

• Problema 115695 resolvido: na página Monitorizar > Edges (Monitor > Edges), um cliente não consegue procurar um Edge por Descrição (Description) na tabela Lista de Edges (Edge List).

  Certas palavras na descrição de um Edge (por exemplo, Ativado ou a localização do Edge) são úteis para procurar todos os Edges com uma descrição semelhante.

• Problema 115837 resolvido: na página Monitorizar > Edges (Monitor > Edges) ou Configurar > Edges (Configure > Edges) da IU do Orchestrator, ao tentar procurar Edges na tabela principal, não é possível pesquisar Edges até todos os Edges serem carregados.

  Ao carregar Edges na tabela principal, o ícone de progresso da lista bloqueia a barra de pesquisa, impossibilitando a sua utilização até que o pedido termine, o que pode levar algum tempo, especialmente se a empresa incluir um grande número de Edges.

• Problema 116021 resolvido: na página Configurar > Edges > Detalhe do certificado (Configure > Edges > Certificated Detail) da IU do Orchestrator, a janela da caixa de diálogo tem pouca utilidade.

  A janela da caixa de diálogo Detalhe do certificado (Certificate Detail) tem 3 barras de deslocamento incorporadas, o que a torna muito apertada e difícil de utilizar corretamente.

• Problema 116524 resolvido: no caso de clientes que subscrevem o Edge Network Intelligence e têm a Análise (Analytics) ativada, na página Monitorizar (Monitor), ao consultar a lista de ligações do lado esquerdo, o utilizador vê duas ligações para Análise (Analytics) com nomes diferentes, mas que são exatamente iguais e redundantes.

  Há duas ligações para o Edge Network Intelligence: Análise de aplicação (Application Analytics) e Análise de ramo (Branch Analytics) e ambas permitem aceder ao mesmo local do ENI. Este problema pode ser corrigido com uma única ligação no lado esquerdo, chamada Edge Network Intelligence.

• Problema 116610 resolvido: os utilizadores não conseguem adicionar uma nova interface de retorno do Edge através da APIv2.

  Não é possível criar uma nova interface de retorno através da operação PATCH ADD via APIv2. A estrutura do esquema para a interface de retorno na APIv2 não permitia interfaces nomeadas pelo ID de interface e, neste cenário, a atualização da interface de retorno falha.

• Problema 116999 resolvido: quando um utilizador operador inicia sessão no VMware SASE Orchestrator, no lado direito do Orchestrator, o menu indica “Menu do parceiro” (Partner Menu).

  Isto pode causar confusão ao operador, que pensa estar a aceder ao menu errado, uma vez que deveria indicar “Menu do operador” (Operator Menu).

• Problema 117001 resolvido: na página Administração > Gestão de utilizadores > Funções (Administration > User Management > Roles) da IU do Orchestrator, o utilizador não consegue consultar todos os tipos de funções/utilizadores numa página.

  A página Funções (Roles) tem paginação, o que significa que nem todas as funções são encontradas numa única página do browser, mas são distribuídas por várias páginas. O problema está relacionado com os controlos de página da IU não serem facilmente visíveis e a correção elimina a paginação e coloca todas as funções e tipos numa página.

• Problema 117020 resolvido: na página Configurar > Serviços de rede (Configure > Network Services) da IU do Orchestrator, se um utilizador selecionar o separador Serviços TACACS (TACACS Services) e tentar eliminar um serviço TACACS, a IU apresentará a cadeia de texto incorreta para confirmar a eliminação.

  Ao eliminar um serviço TACACS, a IU apresenta a cadeia de texto: configuration.networkServices.deleteConfirm. A IU deve apresentar a caixa de diálogo de eliminação correta “Tem a certeza de que deseja eliminar este item?” (Are you sure you wish to delete this item?).

• Problema 117145 resolvido: no site da empresa de um cliente que implementa VNFs, quando um utilizador altera qualquer configuração em Configurar > Dispositivo (Configure > Device), o Orchestrator desativa a VNF.

   O Orchestrator não reimplementa a VNF depois de ser desativada, o que causa uma interrupção significativa para um cliente.

• Problema 117152 resolvido: se um utilizador criar um filtro BGP em que a comunidade tenha valores inteiros superiores a 65535 e o atribuir a um vizinho, o Orchestrator permite esta integração, apesar de o Edge ignorar o filtro.

  O Edge só suporta valores de comunidade no formato AA:NN com valores (0-65535):(0-65535). Se forem introduzidos valores superiores a 65535 como um número inteiro, o Edge ignorará esses valores e o Orchestrator não rejeitará um filtro com um valor superior a 65535.

• Problema 117385 resolvido: o utilizador pode registar alguma lentidão no VMware SASE Orchestrator quando tenta efetuar várias alterações de configuração.

  O cliente não consegue executar várias alterações de configuração no Orchestrator, sendo que as operações demoram até um minuto.

• Problema 117537 resolvido: na página Monitorizar > Edges > Origens (Monitor > Edges > Sources) da IU do Orchestrator, a lista de dispositivos cliente mostra um número incorreto de dispositivos, normalmente um número inferior ao que realmente existe.

  O problema ocorre quando o modo “Visibilidade por endereço IP” (Visibility by IP Address) ou “Visibilidade por endereço MAC” (Visibility by MAC Address) não está definido no módulo de configuração específico do Edge predefinido, mas é definido num módulo associado.

• Problema 117573 resolvido: na página Configurar > Dispositivo > VPN > VPN de cloud (Configure > Device > VPN > Cloud VPN), quando um utilizador tenta configurar um site Ramo a Hub, os Hubs não podem ser filtrados através do ícone de filtragem.

  Quando a empresa de um cliente tem vários Hubs configurados, a falta de filtragem dificulta a configuração de uma VPN Ramo a Hub.

• Problema 117614 resolvido: a página Configurar > Perfil (Configure > Profile) da IU do Orchestrator tem várias ações em falta na caixa Atalhos (Shortcuts).

  Os atalhos em falta incluem: Migrar perfil (Migrate Profile); Duplicar perfil (Duplicate Profile); Modificar perfil (Modify Profile) e Eliminar perfil (Delete Profile). Estas ações podem ser encontradas na página da lista do perfil, mas o cliente deve ter um acesso mais fácil às mesmas.

• Problema 118265 resolvido: na página Gestão de utilizadores (User Management) da IU do Orchestrator, um utilizador administrador com os privilégios corretos não poderá eliminar uma conta de utilizador se tiver utilizado a pesquisa para encontrar essa conta.

  Quando o utilizador utiliza a barra de pesquisa para encontrar o utilizador e utiliza 4 ou mais caracteres, uma vez localizado, o botão Eliminar (Delete) fica a cinzento e não funciona.

• Problema 118302 resolvido: na página Monitorizar > Edge (Monitor > Edge) da IU do Orchestrator, o utilizador não consegue filtrar o estado da ligação para os Edges.

  A API do Orchestrator foi melhorada para aceitar o estado da ligação como um parâmetro de filtro e ajuda a filtrar o estado da ligação no ecrã Lista de Edges (Edge List).

• Problema 118527 resolvido: num VMware SASE Orchestrator implementado como um Orchestrator bastião que utiliza uma Autoridade de certificado externa, os clientes podem observar que um VMware SD-WAN fica offline quando é promovido com êxito.

  Num ambiente bastião, em que o Orchestrator privado está integrado numa Autoridade de certificado externa, o Edge passa para um estado offline logo após a sua promoção a Orchestrator privado.

  Num Orchestrator sem uma correção para este problema, a solução alternativa passa por eliminar a lista de revogação de certificados (CRL) no dispositivo Edge e reiniciar o serviço Edge.

• Problema 118670 resolvido: a página Monitorizar > Serviços de rede > Clusters Edge (Monitor > Network Services > Edge Clusters) pode demorar mais de 30 segundos a carregar.

  Quando uma empresa tem mais de 10 mil serviços de rede, a página Monitorizar > Serviços de rede > Cluster Edge (Monitor > Network Services > Edge Cluster) demora muito tempo a carregar.

• Problema 118761 resolvido: na página Listagem do Edge (Edge Listing), ao utilizar o menu pendente Atribuir imagem de software (Assign Software Image), o utilizador não consegue filtrar imagens de software.

  A falta de filtragem torna o processo de seleção mais difícil quando há muitas imagens de software para selecionar.

• Problema 118764 resolvido: na página Listagens do Edge (Edge Listings), o menu pendente Atribuir perfil do operador (Assign Operator Profile) não permite que os utilizadores filtrem itens.

  A falta de opções de filtro torna o processo de seleção do perfil do operador mais difícil do que deveria.

• Problema 118767 resolvido: na página Visão geral do Edge (Edge Overview), os utilizadores não conseguem filtrar itens nem fazer seleções ao atualizar a seleção da licença Edge.

  A falta de filtragem torna o processo de seleção mais difícil quando há muitas licenças Edge para escolher.

• Problema 121336 resolvido: quando um Edge ou perfil tem a “Atribuição de Gateway de parceiro” (Partner Gateway Assignment) configurada na página Configurar > Dispositivo (Configure > Device) e as alterações são feitas através de uma chamada à API, o evento “Atualização do perfil” (Profile Update) mostra sempre os Gateways como eliminados.

  Trata-se de uma questão puramente cosmética e não tem qualquer efeito funcional. O problema ocorre porque o campo Gateways está obsoleto na configuração.

• Problema 121995 resolvido: um cliente recebe alertas de recuperação automática HA mesmo que tenha desativado esses alertas na página Configurar > Alertas (Configure > Alerts) do Orchestrator.

  Quando os alertas da empresa estão ativados, mas os alertas de recuperação automática HA não estão ativados, o alerta de recuperação automática HA está a ser enviado aos utilizadores empresariais.

• Problema 122940 resolvido: quando um utilizador está na página Gestão de Gateways (Gateway Management), em alguns casos, pode ser redirecionado para o ecrã errado.

  Quando um cliente deseja atribuir um Gateway VPN seguro (Secure VPN Gateway), o Orchestrator deveria redirecionar para o ecrã Atribuir Gateway do Datacenter (Assign Datacenter Gateway), mas redireciona incorretamente para o ecrã Atribuir supergateway (Assign Super Gateway).

• Problema 123593 resolvido: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade em que a Análise (Analytics) do Edge Network Intelligence está ativada, em casos raros, o Edge HA pode não extrair a configuração de análise do back-end do serviço Edge Network Intelligence.

  É possível que os Edges ativos e em standby obtenham o mesmo token do back-end do ENI. Se o Edge em standby obtiver o token depois do Edge ativo, o token do Edge ativo fica obsoleto, resultando neste cenário.

• Problema 123619 resolvido: se um VMware SASE Orchestrator não tiver acesso à Internet (por exemplo, no local), a página Monitorizar > Edge > Visão geral (Monitor > Edge > Overview) estará vazia, ou seja, não apresentará informações.

  Quando o Orchestrator não tem acesso à Internet, a página Visão geral do Edge (Edge Overview) não estará acessível devido à falta de acesso aos serviços Google.

• Problema 123867 resolvido: as APIs de série e as métricas de ligação devolvem um erro.

  Quando as APIs de série ou as métricas de ligação são chamadas sem uma lista de métricas, a API devolve um erro por engano em vez de adicionar todas as métricas aplicáveis à resposta.

  Num Orchestrator sem uma correção para este problema, o utilizador deve enviar um pedido de API com uma lista de campos de métricas a devolver.

• Problema 124092 resolvido: no ecrã Controlo de fluxo de overlay (Overlay Flow Control), o utilizador não consegue ver o nome do segmento.

  Ao tentar filtrar o nome do segmento, este não é preenchido como parte dos resultados.

• Problema 124743 resolvido: no ecrã Monitorizar > Edge > Visão geral (Monitor > Edge > Overview) do VMware SASE Orchestrator, a grelha Estado das ligações (Links Status) nunca conclui o carregamento.

  Não é possível carregar o estado da ligação quando uma ou mais ligações WAN estão configuradas como Backup ou Reserva dinâmica (Hot Standby). Neste caso, existe um estado Backup/Reserva dinâmica (Hot Standby) ausente numa das ligações, o que faz com que a IU falhe.

  O utilizador pode contornar este problema alternando o Modo de ligação (Link Mode) de “Transporte de backup” (Backup Transport) da ligação de “Reserva dinâmica” (Hot Standby) para “Ativo” (Active) e guardar e, em seguida, voltar para “Reserva dinâmica” (Hot Standby).

• Problema 126257 resolvido: o valor na parte superior da página Monitorizar > Edge > Ligações (Monitor > Edge > Links) não está visível para os utilizadores quando há muitos valores extremamente elevados.

  Este problema deve-se ao facto de a altura do gráfico ter sido previamente somada com valores inferiores, o que tornou o gráfico impreciso, não sendo possível alinhá-lo com a escala.

• Problema 127281 resolvido: na página Configurar > Controlo de fluxo de overlay (Configure > Overlay Flow Control) da IU do Orchestrator, as configurações estáticas em subinterfaces routed não aparecem na página OFC como caminhos ligados.

  Quando uma configuração estática é feita numa interface ou subinterface não-WAN routed, espera-se que apareçam na página OFC como caminhos ligados. Mas tal não está a funcionar para as subinterfaces que utilizam configurações IPv6 em que o IPv6 também não está ativado na interface principal da subinterface.

• Problema 127636 resolvido: na página Monitorizar > Edge > Origens (Monitor > Edge > Sources) da IU do VMware SASE Orchestrator, a pesquisa do utilizador de uma origem por FQDN não funciona.

  A funcionalidade Pesquisar por FQDN (Search by FQDN) não está a funcionar conforme esperado ao utilizar a nova IU, o que impede que um utilizador localize uma origem com um método padrão. Isto inclui não ter a opção de pesquisar por uma cadeia de caracteres parcial.

  Pode continuar a procurar por endereço IP, mas deve utilizar uma cadeia de caracteres completa.

• Problema 127849 resolvido: o botão Ver certificado (View Certificate) fica desativado e não é possível clicar no mesmo no ecrã Edge > Configuração > Visão geral (Edge > Configuration > Overview).

  Este problema impede que os utilizadores vejam os certificados do Edge. Sem uma correção da IU, o utilizador pode ver um certificado do Edge ao navegar para a lista do Edge no separador Configuração (Configuration) e procurar o Edge desejado.

Problemas conhecidos

Problemas pendentes na versão 5.2.0.

• Problemas conhecidos do Edge/Gateway
• Problemas conhecidos do Orchestrator

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

  Uma grande atualização de configuração no Gateway de parceiro (por exemplo, 200 VRFs configurados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.

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

• Problema 25921:

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

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

• Problema 25997:

  o VMware SD-WAN Edge pode precisar de um reinício para passar corretamente tráfego numa interface routed que foi convertida para uma porta switched.

  Solução alternativa: reinicie o Edge após fazer a alteração de configuração.

• Problema 26421:

  O Gateway de parceiro primário para qualquer site do ramo também deve ser atribuído a um cluster do VMware SD-WAN Hub para túneis ao cluster a ser estabelecido.

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

• Problema 28175:

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

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

• Problema 31210:

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

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

• Problema 32731:

  os caminhos predefinidos condicionais anunciados através de OSPF podem não ser retirados corretamente quando o caminho é desativado.

  Solução alternativa: a reativação do caminho, seguida de uma nova desativação, permitirá retirá-los com sucesso.

• Problema 32960:

  o estado da interface de “Negociação automática” (Autonegotiation) e “Velocidade” (Speed) pode ser apresentado incorretamente na IU de Web Local para os VMware SD-WAN Edges ativados.

  Solução alternativa: consulte a IU do Orchestrator em Diagnóstico remoto > Estado da interface (Remote Diagnostics > Interface Status).

• Problema 32981:

  A codificação da velocidade e do duplex numa porta configurada por DPDK pode exigir o reinício do VMware SD-WAN Edge para que as configurações entrem em vigor, uma vez que exige a desativação do DPDK.

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

• Problema 34254:

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

• Problema 35778:

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

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

• Problema 36923:

  o nome do cluster não pode ser atualizado corretamente na descrição da interface de NetFlow para um VMware SD-WAN Edge que está ligado a esse Cluster como o seu Hub.

• Problema 38682:

  Um VMware SD-WAN Edge que atua como um servidor DHCP numa interface configurada por DPDK pode não gerar corretamente eventos de “Novo dispositivo de cliente” para todos os clientes ligados.

• Problema 38767:

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

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

• Problema 39374:

  alterar a ordem dos Gateways de parceiro do VMware SD-WAN atribuídos a um VMware SD-WAN Edge pode não definir corretamente o Gateway 1 como o Gateway local a ser utilizado para o teste de largura de banda.

• Problema 39608:

  a saída do “Teste de Ping” (Ping Test) de Diagnóstico Remoto pode apresentar brevemente conteúdos inválidos, antes de apresentar os resultados corretos.

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

• Problema 39624:

  o ping através de uma subinterface pode falhar quando a interface principal estiver configurada com PPPoE.

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

• Problema 39753:

  a desativação da VPN ramo a ramo dinâmica pode fazer com que os fluxos existentes que estão atualmente a ser enviados através da mesma fiquem parados.

  Solução alternativa: basta desativar a VPN Ramo a Ramo Dinâmica numa janela de manutenção.

• Problema 40421:

  O Traceroute não está a apresentar o caminho quando passa através de um VMware SD-WAN Edge com uma interface configurada como uma porta switched.

• Problema 40096:

  se um VMware SD-WAN Edge 840 ativado for reiniciado, existirá possibilidade de um módulo SFP ligado ao Edge parar de passar o tráfego, mesmo que as luzes de ligação e o VMware SD-WAN Orchestrator indiquem a porta como “ATIVA” (UP).

  Solução alternativa: desligue o módulo SFP e, em seguida, volte a ligá-lo na porta.

• Problema 42278:

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

• Problema 42872:

  Ativar o isolamento de perfil num perfil de Hub em que um Cluster de Hub está associado não revoga os caminhos do Hub na base de informações de encaminhamento (RIB).

• Problema 43373:

  quando o mesmo caminho BGP é aprendido a partir de vários VMware SD-WAN Edges, se este caminho for movido da saída preferencial para a saída elegível no Controlo de fluxo de overlay, o Edge não será removido da lista de anúncios e continuará a ser anunciado.

  Solução alternativa: ative o cálculo de custos distribuídos (DCC) no VMware SD-WAN Orchestrator.

• Problema 44995:

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

• Problema 45189:

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

• Problema 45302:

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

• Problema 46053:

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

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

• Problema 46137:

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

  Solução alternativa: Se um cliente estiver a utilizar o AES-256, deverá desativar explicitamente o GCM do Orchestrator antes de atualizar os Edges para a versão 4.x. Uma vez que todos os Edges estão a executar a versão 4.x, o cliente pode escolher entre o AES-256-GCM e o AES-256-CBC.

• Problema 46216:

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

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

• Problema 46391:

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

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

• Problema 47664:

  numa configuração de Hub e Spoke onde a VPN ramo a ramo através do Hub está desativada, tentar inverter o sentido do tráfego ramo a ramo com um caminho resumido num switch/router L3 provocará ciclos de routing.

  Solução alternativa: configure a VPN de cloud para ativar a VPN ramo a ramo e selecione “Utilizar Hubs para VPN” (Use Hubs for VPN).

• Problema 47681:

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

• Problema 48530:

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

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

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

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

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

• Problema 50518:

  Num VMware SD-WAN Gateway onde o PKI está configurado, se mais de 6000 túneis PKI tentarem ligar-se ao Gateway, os túneis poderão não surgir todos devido aos SAs de entrada não serem eliminados.

  Os túneis que utilizam a autenticação de chave pré-partilhada (PSK) não têm este problema.

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

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

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

• Problema 52955: A recusa DHCP não é enviada a partir do Edge e o reenlace do DHCP não é reiniciado após a falha do DAD no DHCP Dinâmico.

  Se o servidor DHCPv6 atribuir um endereço que é detetado como duplicado pelo kernel durante uma verificação DAD, o cliente DHCPv6 não enviará nenhuma recusa. Isto levará a tráfego ignorado, uma vez que o endereço de interface será assinalado como verificação DAD falhada e não será utilizado. Esta ação não levará a nenhum ciclo de tráfego na rede, mas será observado um bloqueio de tráfego.

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

• Problema 53219: após um reequilíbrio do cluster do VMware SD-WAN Hub, alguns Spoke Edges podem não ter a interface RPF/IIF com a definição correta.

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

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

• Problema 53934: numa empresa onde está configurado um cluster do VMware SD-WAN Hub, se o Hub principal tiver vizinhanças BGP multihop no lado LAN, o cliente poderá sofrer situações de tráfego ignorado num Spoke Edge quando existir uma falha do lado LAN ou quando o BGP não for configurado em todos os segmentos.

  Num cluster de Hub, o Hub principal tem a vizinhança BGP multihop com um dispositivo de par para aprender caminhos. Se a interface física no Hub, através da qual a vizinhança do BGP é estabelecida, ficar inativa, os caminhos da BGP LAN não poderão ser zero, apesar da vista BGP estar vazia. Isto pode fazer com que o reequilíbrio do Cluster de Hub não ocorra. O problema também pode ser observado quando o BGP não está configurado para todos os segmentos e quando existem uma ou mais vizinhanças BGP multihop.

  Solução alternativa: reinicie o Hub que teve a falha do lado da LAN (ou o BGP não ativado).

• Problema 57210: mesmo quando um VMware SD-WAN Edge está a funcionar normalmente e é capaz de aceder à Internet, o LED na página Visão geral (Overview) da IU local é apresentado como “Vermelho” (Red).

  A IU local do Edge determina a conetividade do Edge com base na capacidade do mesmo para resolver um nome conhecido através da resolução de DNS do Google (8.8.8.8). Se não o conseguir por qualquer motivo, pensa que está offline e apresenta o LED como vermelho.

  Solução alternativa: não existe uma solução alternativa para este problema, exceto garantir que o tráfego DNS para 8.8.8.8 consegue alcançar o destino e ser resolvido com sucesso.

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

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

  Solução alternativa: não existe uma solução alternativa para este problema, para além de garantir que não está configurada mais de uma regra NAT 1:1 com um endereço IP interno específico.

• Problema 65560: o tráfego de um cliente para o dispositivo PE (Edge do Fornecedor) falha.

  A vizinhança BGP entre um Gateway de parceiro e o Edge do Fornecedor não é estabelecida quando o tipo de etiqueta é selecionado como “nenhum” na configuração de handoff de informação. Isto porque os valores ctag e stag são escolhidos em /etc/config/gateway e não na configuração da handoff de informação no Orchestrator quando o tipo de etiqueta é “nenhum”.

  Solução alternativa: atualize os valores ctag e stag para 0 cada em vrf_vlan->tag_info em /etc/config/gatewayd. Efetue um reinício vc_procmon.

• Problema 67879: um túnel do Serviço de Segurança na Cloud (CSS) é eliminado depois de um utilizador alterar uma definição de overlay WAN na deteção automática para definida pelo utilizador numa definição da interface WAN.

  Depois de guardar as alterações, os túneis CSS não voltam a ficar ativos sem que o cliente desative os túneis e volte a ativá-los. A alteração da configuração WAN desativará o túnel CSS e analisará novamente a configuração do CSS. Todavia, em alguns casos, o nvs_config>num_gre_links é 0 e o túnel CSS não fica ativo.

  Solução alternativa: desativar a configuração de CSS e, em seguida, reativá-la, ativará o túnel CSS.

• Problema 68057: O pacote da versão DHCPv6 não é enviado do VMware SD-WAN Edge quando se altera o modo de endereço da interface WAN de DHCP com estado para endereço IPv6 estático e a concessão permanece ativa até atingir o tempo válido correspondente.

  O cliente DHCPv6 tem uma concessão que não é libertada quando a configuração é alterada. A concessão permanece válida até a sua vida útil expirar no servidor DHCPv6 e ser eliminada.

  Solução alternativa: não há forma de remediar este problema, uma vez que a concessão permanece ativa até ao fim da sua vida útil.

• Problema 68851: se um VMware SD-WAN Edge e VMware SD-WAN Gateway tiverem o mesmo servidor TCP syslog configurado, a ligação TCP não será estabelecida do Edge para o servidor syslog.

  Se o Edge e o Gateway tiverem cada um o mesmo servidor TCP e se os pacotes syslog do Edge forem encaminhados através do Gateway, o servidor syslog enviará uma redefinição do TCP para o Edge.

  Solução alternativa: envie os pacotes syslog diretamente do Edge em vez de os encaminhar através de um Gateway ou configure um servidor syslog diferente para o Edge e o Gateway.

• Problema 69284: num site que utilize uma topologia de alta disponibilidade na qual os Edges implementem VNFs numa configuração HA e estejam a utilizar a versão 4.x, se estes Edges HA forem mudados para a versão inferior 3.4.x, que não suporta VNFs HA, e, em seguida, atualizados para 4.5.0, quando os VNFs HA forem reativados, a VNF no Standby Edge não será ativada.

  O estado VNF no Edge em standby é comunicado como inativo através do SNMP. Se o par VNF HA for mudado para uma versão anterior, de uma versão que suporte VNF-HA (versão 4.0+) para uma versão que não a suporte com a VNF configurada no Orchestrator. Este problema ocorre quando o Edge é atualizado para uma versão que suporta a VNF-HA e é configurado no Orchestrator novamente.

  Solução alternativa: a VNF deverá primeiro ser desativada no caso de uma configuração HA se o Edge for mudado para uma versão anterior que não a suporta.

• Problema 72358: se o endereço IP de um nome DNS do VMware SD-WAN Orchestrator for alterado, o processo do plano de gestão do VMware SD-WAN Gateway não o resolverá corretamente e o Gateway não poderá ligar ao Orchestrator.

  O processo de gestão do Gateway verifica periodicamente a resolução de DNS do

  nome DNS do Orchestrator, para ver se mudou recentemente, de forma a que o Gateway se possa ligar ao anfitrião correto. O código de resolução do DNS tem um problema, pelo que todas as verificações de resolução falham e o Gateway continua a utilizar um endereço antigo e, como tal, deixa de conseguir ligar-se ao Orchestrator.

  Solução alternativa: até que este problema seja resolvido, um utilizador operador não deve alterar o endereço IP do Orchestrator. Se o endereço IP do Orchestrator tiver de ser alterado, todos os Gateways ligados a esse Orchestrator terão de ser reativados.

• Problema 75171: um utilizador cliente do Edge não receberá nenhum endereço IP se o servidor DHCP estiver configurado num site de Destino Não-SD-WAN via Gateway em que o Edge atua como um agente de reencaminhamento.

  O problema deve-se ao facto de as mensagens Oferta DHCP (DHCP Offer) serem rejeitadas pelo Edge porque o código do Edge não tem em conta esta configuração DHCP.

  Solução alternativa: localize o servidor DHCP em qualquer lugar que não seja um Destino Não-SD-WAN.

• Problema 77541: Quando um modem USB que suporta o IPv6 é desligado e, em seguida, ligado novamente a uma interface USB do VMware SD-WAN Edge, pode não ser aprovisionado um endereço IPv6 na interface USB.

  Isto afeta modems USB baseados em IP, versus geridos pela aplicação ModemManager. A maioria dos modems Inseego são baseados em IP e isso é importante porque o Inseego é o fabricante de modem que o VMware SASE recomenda. Os modems USB que suportam o IPv6 e utilizam o ModemManager versus baseados em IP serão bons num cenário de desligar e ligar novamente.

  Solução alternativa: O Edge tem de ser reiniciado (ou desligado e ligado) depois de o modem USB ser ligado novamente na porta USB do Edge. Após o reinício, o Edge irá recuperar o endereço IPv6 para o modem.

• Problema 81852: para um VMware SD-WAN Edge que está a utilizar um Serviço de Segurança na Cloud (CSS) do tipo Zscaler que utiliza túneis GRE e ativou a Verificação de estado de funcionamento de L7 (L7 Health Check), quando esse Edge é atualizado para a versão 5.0.0, em alguns casos, o cliente pode observar erros de verificação de estado de funcionamento de L7.

  Isto é normalmente visto durante a atualização do software ou durante o tempo de arranque. Quando a Verificação de estado de funcionamento de L7 (L7 Health Check) verifica se existe um CSS com túneis GRE, podem ser observadas mensagens de erro getaddress relacionadas com o socket. O erro observado é visto de forma intermitente e não consistente. Por causa disso, as mensagens de sonda da Verificação de estado de funcionamento de L7 (L7 Health Check) não são enviadas.

  Solução alternativa: Sem a correção, para remediar o problema, um utilizador tem de desligar e depois voltar a ligar a configuração da Verificação de estado de funcionamento de L7 (L7 Health Check) e esta funcionalidade funciona então como esperado.

• Problema 82184: num VMware SD-WAN Edge a executar a versão 5.0.0 do Edge, quando um traceroute ou traceroute6 é executado para o endereço IPv4/IPv6 de br-network do Edge, o traceroute não vai terminar corretamente quando é utilizada uma sonda UDP.

  O traceroute ou traceroute6 para o endereço IPv4/IPv6 de br-network do Edge não será corretamente utilizado quando for utilizado o modo predefinido (por outras palavras, a sonda UDP).

  Solução alternativa: Utilize a opção -I em traceroute e traceroute6 para utilizar a pesquisa ICMP e depois o traceroute para o endereço IPv4/IPv6 de br-network funcionará como esperado.

• Problema 83166: Quando um VMware SD-WAN Gateway é recentemente implementado com um tipo de instância AWS c5.4xlarge do Portal do AWS com a opção IPv6 selecionada, nem o IPv6 nem os caminhos predefinidos estão configurados.

  Como resultado do IPv6 e dos caminhos predefinidos não configurados, os túneis de gestão do Gateway IPv6 do AWS não estão a formar-se e o Gateway não irá funcionar.

  Solução alternativa: não existe uma solução para este problema, evite a implementação de um Gateway com as propriedades acima mencionadas.

• Problema 85402: no caso da empresa de um cliente que utiliza o BGP com Gateways de parceiro configurados, o utilizador pode verificar que algumas vizinhanças BGP estão inativas e isso provoca problemas de tráfego do cliente.

  Se o cliente tiver o prefixo máximo configurado num router que tenha pares BGP com o Edge e o Gateway, a sessão BGP poderá ser descartada pelo router.

  Por exemplo, se o router tiver o BGP configurado para receber apenas o número “n” máximo de prefixos, mas o Edge e o Gateway tiverem mais de “n” prefixos a serem anunciados na ausência de quaisquer filtros. Contudo, se a configuração do filtro BGP for alterada no Orchestrator, mesmo que o número total de prefixos permitidos na direção de saída seja menor que “n”, o problema surgirá onde mais de “n” forem enviados para o par antes que qualquer filtro seja aplicado. Isso faz com que o router termine a sessão.

  Solução alternativa: se o BGP ficar inativo devido a este problema (Número máximo de prefixos alcançados), efetue um flap BGP no par utilizando a CLI (Para FRR/Cisco, “neighbor x shut” seguido de “no neighbor x shut”). O BGP criará apenas o número desejado de prefixos anunciados para o par.

• Problema 92481: se uma interface WAN num VMware SD-WAN Edge estiver desativada no VMware SASE Orchestrator, o SNMP continuará a comunicar a interface como “Ativa” (UP).

  O processo de depuração principal para a saída das interfaces não inclui os detalhes da porta física para interfaces WAN do Edge (por exemplo, GE3 ou GE4 num modelo Edge 6x0 ou 3x00). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.

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

• Problema 93141: num site implementado com uma topologia de alta disponibilidade, um cliente que utiliza um interruptor L2 a montante do par Edge HA pode observar evidências de um ciclo de tráfego L2 nos registos do interruptor, embora não exista realmente um ciclo.

  O problema é provocado pelo Edge HA enviar o heartbeat da interface HA com o endereço MAC virtual para o Orchestrator em vez do endereço MAC real da interface, o que é causado pelo Edge HA armazenar o endereço MAC virtual no ficheiro MAC. Como resultado, o interruptor L2 ligado deteta tráfego do mesmo MAC de origem proveniente de duas interfaces Edge diferentes e regista-o como um ciclo L2. Este problema é cosmético ao nível do registo, dado que não existe realmente um ciclo L2 e não existe nenhuma interrupção do tráfego do cliente nem perda de contacto com o Orchestrator decorrente do mesmo.

  Solução alternativa: o cliente pode ignorar os eventos de deteção de ciclo L2 dos interruptores a montante provenientes da interface de HA do Edge (normalmente GE1).

• Problema 95399: Quando uma ligação Ethernet é fisicamente desligada ou ligada a uma interface VMware SD-WAN Edge, o VMware SASE Orchestrator não recebe uma notificação deste evento do Edge e não o mostra em Eventos de cliente.

  Os clientes confiam no Orchestrator para reportar estes eventos na página Eventos e quando estes não são registados, isso torna a monitorização dos seus vários sites menos fiável.

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

• Problema 95565: Num site que utilize uma topologia de alta disponibilidade, o Edge Ativo do VMware SD-WAN pode sofrer uma falha do Serviço Dataplane com um núcleo gerado e aciona a recuperação automática de alta disponibilidade.

  O problema é acionado pelas ligações WAN do Edge ativo ficarem instáveis uma ou mais vezes (ficam inativas e rapidamente voltam a estar ativas) enquanto utilizam em simultâneo o SNMP onde existem consultas SNMP frequentes. Existe um problema de temporização onde o regresso da interface e a consulta SNMP em conjunto podem acionar um bloqueio total que faz com que o serviço Dataplane falhe e gere um núcleo. Embora uma única instabilidade da ligação WAN possa provocar este problema, quanto maior a frequência das instabilidades da ligação WAN, maior o potencial para este problema ocorrer.

  Solução alternativa: num par Edge HA que regista este problema e não tem a correção, a solução alternativa é desativar o SNMP, uma vez que se trata de um problema de temporização e isto reduz o risco.

• Problema 97559: No site de um cliente implementado com uma topologia de alta disponibilidade melhorada, uma ligação WAN ligada ao VMware SD-WAN Edge numa função Em standby (Standby) pode aparecer como inativa no VMware SASE Orchestrator e não transmitir o tráfego do cliente, mesmo que a interface WAN do Edge onde a ligação WAN está ligada esteja ativa.

  Um utilizador que analisasse um tcpdump ou o registo de um pacote de diagnóstico observaria pedidos de ARP a chegar e o Edge em espera a não responder, como resultado do bloqueio da respetiva porta. Na HA melhorada, quando um Edge assume a função Em espera, devem ocorrer os seguintes eventos nesta sequência:

  1. O Edge em standby bloqueia todas as portas.

  2. O Edge em standby deteta que está implementado numa topologia de HA melhorada e desbloqueia as respetivas portas WAN para transmitir o tráfego.

  Quando este problema ocorre, Evento 1, o bloqueio inicial das portas demora inesperadamente muito tempo a ser concluído e o Evento 2 seguinte, o desbloqueamento de todas as portas WAN, é concluído antes da conclusão do Evento 1. Em seguida, o Evento 1 é concluído e, assim, o estado final é que todas as portas WAN estão bloqueadas no Edge em standby.

  Solução alternativa: Num Edge HA sem uma correção para este problema, a solução alternativa é forçar uma recuperação automática de HA que promove o Edge em standby a ativo e apresenta as ligações WAN do Edge de HA.

• Problema 98136: Para as empresas de clientes que usam uma topologia Hub/Spoke onde a VPN Ramo a Ramo Dinâmica está configurada, os utilizadores cliente atrás de um SD-WAN Edge Spoke podem observar que algum tráfego tem latência inesperada, resultante do tráfego utilizar um caminho que não o ideal.

  O tráfego do Edge Spoke que regista este problema utiliza um caminho que era inicialmente um caminho de não transmissão para um Hub Edge não incluído no perfil que o Edge Spoke estava a utilizar. Um túnel de VPN Ramo a Ramo Dinâmica pode ser formado do Edge Spoke para o Edge Hub devido ao tráfego ser enviado em direção a outro prefixo não relacionado e, nesta instância, um caminho não de transmissão é instalado no Edge Spoke.

  Em resultado deste caminho não-transmissão, todo o tráfego para este prefixo começa a passar pelo

  O Hub Edge e o caminho não-transmissão torna-se num caminho de transmissão (alteração para comunidade de transmissão), mas o caminho não-transmissão instalado previamente não é revogado e o tráfego assume o caminho de Hub Edge enquanto o túnel de VPN ramo a ramo Dinâmica permanecer ativa.

  Solução alternativa: aguarde que o túnel da VPN Ramo a Ramo Dinâmica fique inativo, após isso, o caminho de transmissão não será instalado no Edge Spoke quando um novo túnel da VPN Ramo a Ramo Dinâmica é formado em direção ao Edge Hub.

• Problema 102583: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade com VNFs instaladas, com o par Edge HA ou os modelos Edge 520/540 ou 610, a acessibilidade à VNF do Edge em standby a partir de um cliente ligado à LAN pode falhar.

  A placa de comutação Ethernet nestes modelos Edge remove os pacotes de resposta ARP enviados a um cliente LAN a partir de uma VNF do Edge em standby, o que causa uma perda de acessibilidade.

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

• Problema 106289: um VMware SD-WAN Hub Edge pode descartar pacotes em fluxos para Spoke Edges ligados ou fluxos de backhaul.

  O sinalizador de fluxo de backhaul é definido durante o processo de sincronização de QoS, existe um ponto no código em que o define durante a criação do fluxo. O Edge deve definir este sinalizador apenas como resultado do processamento de mensagens de sincronização de QoS.

  Solução alternativa: se este problema surgir num Hub Edge sem uma correção, limpe os fluxos no Hub Edge para corrigir temporariamente o problema.

• Problema 109771: um VMware SD-WAN Edge pode não conseguir estabelecer um túnel com um Destino Não-SD-WAN via Edge de tipo Cisco CSR/ASE quando o NAT66 é aplicado no meio.

  Se, entre dois pares, um NAT de endereço IPv6 de origem estiver envolvido com um Cisco CSR/ASA, não será estabelecido nenhum túnel.

  Solução alternativa: num Edge sem uma correção para este problema, a única coisa que um utilizador poderá fazer é atualizar o Cisco CSR/ASA para uma versão de software Cisco que suporte NAT66 através de IPsec.

• Problema 110561: os túneis dinâmicos podem não aparecer no mesmo conjunto de VMware SD-WAN Edges com tráfego bidirecional quando o tráfego para e, em seguida, é reiniciado.

  O problema é observado num ambiente de teste em que existem 6000 túneis dinâmicos com tráfego bidirecional elevado que é enviado entre os Edges. Mesmo em testes de menor escala com 1000 túneis dinâmicos, nem todos os túneis aparecem.

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

• Problema 111085: quando uma ligação WAN do VMware SD-WAN Edge é configurada com um endereço IP na mesma rede que o IP de retorno do Edge, o Edge utiliza o endereço MAC da interface WAN enquanto responde a um pedido ARP para o endereço IP de retorno do Edge.

  Isso pode provocar uma falsificação (spoof) do ARP e resultar na depreciação do IP de gestão e, consequentemente, em perturbações da rede.

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

• Problema 111592: na empresa de um cliente que utiliza uma topologia Hub/Spoke em que as políticas empresariais estão configuradas para utilizar o backhaul de Internet, o tráfego da Internet que utiliza a regra de backhaul pode ser lento ou não funcionar.

  Em certos casos, durante a criação do fluxo, a correspondência da política empresarial é alterada devido às informações atualizadas da Inspeção profunda de pacotes (DPI). Isto pode levar à perda do ID lógico do Hub Edge ou do Destino Não-SD-WAN, que é suposto fazer o backhaul dos pacotes.

  Solução alternativa: remova os fluxos para forçar os fluxos a serem reinspecionados pelo motor de DPI.

• Problema 117876: no site de um cliente que utiliza uma topologia de alta disponibilidade, se um utilizador ativar ou desativar os Serviços de firewall melhorados, um Edge HA do VMware SD-WAN poderá sofrer várias reinicializações.

  Quando os Serviços de firewall melhorados são ativados ou desativados, apenas a configuração das Definições do dispositivo do Edge ativo é sincronizada imediatamente com o Edge em standby, com a restante sincronização de configuração apenas em resposta a um heartbeat Edge em standby. Quando o Edge ativo é reiniciado para aplicar a configuração mais recente antes de receber um heartbeat Edge em standby, ocorrerá uma não correspondência da configuração entre os dois Edges HA e serão realizadas várias reinicializações para concluir a sincronização de configuração.

  Solução alternativa: A única solução é ativar ou desativar os Serviços de firewall melhorados durante uma janela de manutenção dos Edges HA.

• Problema 111840: na empresa de um cliente implementada com uma topologia Hub/Spoke que utiliza 9 ou mais Hub Edges, os utilizadores cliente podem registar má qualidade do tráfego devido ao routing inferior ao ideal.

  Quando um Spoke Edge é configurado com vários Hub Edges, é preferível utilizar um caminho via Hub Edge em vez de um caminho direto, o que resulta num routing inferior ao ideal.

  Solução alternativa: configure os Hub Edges primeiro, seguidos pelos Hubs VPN na lista de sites Ramo a Hub.

• Problema 120309: as combinações de certos clientes e servidores da VPN do Protocolo PPTP podem não conseguir restabelecer imediatamente uma ligação após esta ser interrompida ao utilizar NAT 1:1 com a Internet PPTP e o dispositivo cliente atrás do Edge. Foi confirmado que este problema ocorre com um cliente Windows Server 2016 e Windows 10, mas também pode ocorrer com outras versões.

  O problema é causado pelo servidor que está a reutilizar o mesmo call-id PPTP para a nova ligação, enquanto o cliente utiliza um novo call-id. Quando o call-id do servidor é reutilizado para a nova ligação, a firewall não o identifica como tal.

  Num Edge sem uma correção para este problema, a solução alternativa passa por remover a ligação PPTP obsoleta da tabela NAT.

  O mesmo problema pode ocorrer com as localizações de rede do cliente e do servidor trocadas (por outras palavras, o servidor PPTP na LAN atrás do Edge e o cliente na Internet/Cloud). Esta versão do problema é acompanhada pelo pedido 109830. A correção aqui aborda especificamente clientes do Windows Server 2016. Os clientes do Windows 10 continuam a apresentar este problema e este não é resolvido por esta correção.

  Solução alternativa: remova a ligação PPTP obsoleta da tabela NAT.

• Problema 121281: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade, em casos raros, o cliente pode observar que o Edge em standby registou uma falha no Serviço dataplane, gerou um núcleo e foi reiniciado para recuperar.

  Deveria existir um evento sobre o reinício do Edge em standby. Se o utilizador configurar um alerta de falha de HA, será notificado desse evento. O problema ocorre em cenários raros quando um caminho é sincronizado entre ativo e em standby e o serviço Edge em standby falha devido a corrupção de memória durante o processamento da mensagem de sincronização de caminhos.

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

• Problema 121371: na empresa de um cliente configurada para utilizar Hub e Cluster Interconnect em que a firewall com estado ou a firewall melhorada também é utilizada, os utilizadores cliente podem observar quedas de tráfego.

  O routing assimétrico pode ocorrer entre os nós do Hub de Cluster de origem e de destino, de modo que o tráfego de saída siga um túnel de overlay direto enquanto o tráfego de retorno assume um caminho underlay

  Solução alternativa: a única solução alternativa é desativar os serviços de firewall com estado ou firewall melhorada.

• Problema 121606: as empresas de clientes que utilizam Gateways de parceiros podem observar quedas de tráfego para alguns tipos de tráfego, incluindo Destinos Não-SD-WAN que utilizam esse Gateway.

  A versão 5.1.0 e posteriores dos Gateways de parceiro suportam um máximo de 64 endereços IP por interface IPsec. Para um Gateway de parceiro, os IPs de handoff estão a ser adicionados a esta interface IPsec sem restrições. Se o número de endereços IP de handoff exceder o limite de 64, os endereços IP mais antigos serão substituídos no processo IPsec, o que faz com que os túneis que utilizam esses endereços IP substituídos fiquem desativados.

  Solução alternativa: se todos os endereços IP de handoff do PG estiverem configurados conforme o esperado, não haverá outra solução além de mover alguns desses endereços para um PG diferente (por exemplo, mover um NSD via Gateway). No entanto, se existirem endereços IP de handoff do PG desnecessários, a sua remoção poderá ajudar se reduzir os endereços IP para menos de 64. Após uma alteração da configuração, o serviço do Gateway tem de ser reiniciado.

• Problema 121805: num VMware SD-WAN Edge implementado com VNF, quando se faz o ping para uma VNF local, o utilizador pode observar respostas duplicadas.

  O problema ocorre quando um ping para o IP de uma VNF é feito a partir do Edge.

  Solução alternativa: faça sempre o ping de um cliente LAN atrás do Edge, não no próprio Edge.

• Problema 121998: no caso de um cliente que utiliza a firewall com estado numa topologia Hub/Spoke, o tráfego que corresponde a uma regra de firewall configurada para o tráfego Spoke para Hub, em que a regra inclui uma VLAN de origem, poderá ser descartado.

  Quando há uma alteração na versão da classificação da aplicação, da tabela da política empresarial ou da tabela de política de firewall, o SD-WAN executa uma pesquisa de fluxos na firewall no seu próximo pacote. Devido a um problema de temporização, esse pacote pode ser um do lado do tráfego de gestão (VCMP). Como resultado, durante a criação de uma chave de pesquisa de política de firewall, o SD-WAN troca a VLAN do Spoke Edge pela VLAN do Hub Edge, o que causa a falta de correspondência com a regra e ao descarte do tráfego.

  Solução alternativa: o cliente pode alterar a Origem (Source) de uma VLAN do Edge para “Qualquer” (Any)'.

• Problema 123379: no site da empresa de um cliente implementado com uma topologia de alta disponibilidade, em casos raros, o cliente pode observar que o Edge em standby apresenta uma falha no Serviço dataplane e é reiniciado para recuperar.

  Este problema pode ocorrer quando um utilizador tenta configurar o endereço IPv6 em subinterfaces em 128 segmentos simultaneamente através de um script. Neste cenário, as configurações ficam acumuladas numa fila e isso faz com que o serviço Edge em standby falhe.

  Solução alternativa: é aconselhável configurar configurações de endereços IPv6 em subinterfaces em grupos mais pequenos para que o sistema tenha tempo de processar e aplicar as configurações.

• Problema 125509: a empresa de um cliente que utiliza modelos VMware SD-WAN Edge de baixo custo pode ter flaps para BFD, BGP ou OSPF, dependendo do protocolo de routing utilizado.

  Em plataformas Edge de nível de entrada (510, 520, 540, 610 e 620), a uma escala de fluxo elevado e juntamente com routing dinâmico e/ou configuração de alta disponibilidade, podem ser observados flaps de routing OSPF/BGP quando são configurados temporizadores agressivos de intervalos Hello e Dead. Além disso, se o cliente também utilizar o serviço Edge Network Intelligence com a Análise (Analytics) ativada, a possibilidade de encontrar este problema aumentará.

  Solução alternativa: se este problema ocorrer, a solução alternativa será reverter para temporizadores de intervalo predefinidos para OSPF (10, 40) ou BGP (60, 180) ou desativar completamente o BFD.

• Problema 127920: uma pesquisa ICMP ligada a um caminho estático com um IP secundário como próximo hop pode ficar inativa mesmo que o endereço IP secundário esteja ativo e acessível.

  Quando uma pesquisa ICMP está ligada a um caminho estático com um IP secundário como próximo hop, a pesquisa tem como origem o endereço IP da interface principal em vez do endereço IP secundário. Quando o par não consegue alcançar o endereço IP principal, a pesquisa ICMP é desativada, embora o IP secundário esteja ativo e acessível.

  Solução alternativa: não há nenhuma solução alternativa neste cenário, além de não utilizar um endereço IP secundário.

• Problema 128379: um caminho de resumo BGP que um Spoke Edge anuncia para um Hub Edge através de um backbone MPLS pode entrar num ciclo de retirada e anúncio.

  A sequência que leva a este problema é a seguinte:

  1. O Spoke Edge adiciona o respetivo número ASN (Número de sistema autónomo) e anuncia o prefixo de resumo BGP para o router do Edge do cliente (CE). Em seguida, o CE adiciona o respetivo ASN e anuncia-o ao Hub Edge.

  2. O Hub Edge redistribui o prefixo de resumo no overlay (com o protocolo de gestão do SD-WAN VCRP) com todos os ASNs recebidos. O Hub Edge também redistribui os prefixos que recebeu através do uplink.

  3. O Spoke Edge também recebe o mesmo prefixo de resumo através do VCRP com o ASN do CE. O Spoke Edge redistribui este prefixo de overlay para o BGP. Uma vez que as-set está ativado na configuração agregada, o BGP recolhe os ASNs do prefixo de overlay e adiciona-os ao AS_PATH do prefixo de resumo.

  4. Agora, o CE recebe o prefixo de resumo com o AS_PATH atualizado. Como o ASN do CE faz parte do AS_PATH atualizado, o CE rejeita o prefixo de resumo e retira-o do Hub Edge. Em seguida, o Hub Edge retira-o do Spoke Edge através do VCRP.

  5. Agora, o Spoke Edge altera o AS_PATH do prefixo de resumo BGP de volta para o normal e anuncia-o novamente. Este ciclo repete-se indefinidamente.

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

Problemas conhecidos do Orchestrator

• Problema 21342:

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

• Problema 24269:

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

• Problema 25932:

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

• Problema 32335:

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

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

• Problema 32435:

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

• Problema 32856:

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

• Problema 35658:

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

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

• Problema 35667:

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

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

• Problema 36665:

  Se o VMware SD-WAN Orchestrator não conseguir ligar-se à Internet, as páginas de interface do utilizador que requerem acesso à API do Google Maps poderão não conseguir carregar completamente.

• Problema 32913:

  Após ativar a alta disponibilidade, os detalhes de multicast do VMware SD-WAN Edge não são apresentados na página de monitorização. Uma recuperação automática resolve o problema.

• Problema 33026:

  A página “Acordo de Serviços do Utilizador Final” (End User Service Agreement [EUSA]) não é atualizada corretamente após eliminar o acordo.

• Problema 38056:

  O ficheiro export.csv de licenciamento de Edge não mostra os dados da região.

• Problema 38843:

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

• Problema 39633:

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

• Problema 39790:

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

• Problema 41691:

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

• Problema 43276:

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

  Solução alternativa: remova temporariamente a configuração do Gateway de parceiro no Perfil ou no Edge para que o segmento possa ser alterado entre privado e normal. Em alternativa, o utilizador pode remover o segmento do perfil e fazer a alteração a partir daí.

• Problema 47713:

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

• Problema 47820:

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

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

  Ao encontrar este problema, o utilizador deveria ver uma mensagem de erro semelhante a “ID de VLAN [xx] não pode ser removida, em utilização pelo Edge [b1-edge1 (GEx-desativado)]” (VLAN ID [xx] cannot be removed, in use by edge [b1-edge1 (GEx-disabled]).

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

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

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

• Problema 60522: Na IU do VMware SD-WAN Orchestrator, o utilizador observa um grande número de mensagens de erro quando tenta remover um segmento.

  O problema pode ser observado ao adicionar um segmento a um perfil e associar o segmento a vários VMware SD-WAN Edges. Quando o utilizador tenta remover o segmento adicionado a partir do perfil, vê um grande número de mensagens de erro.

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

• Problema 82680: Para o cliente a utilizar a Automação de Túnel MT-GRE, quando um utilizador desliga a flag Interligação cloud a cloud (CCI) num VMware SD-WAN Gateway que está configurado para utilizar o CCI, as entradas Zscaler MT-GRE podem não ser eliminadas do portal Zscaler de forma consistente.

  Depois de um site CCI ter sido eliminado do Gateway, as entradas para este site também devem ser removidas. Este problema só foi visto durante a automação de teste e não foi reproduzido manualmente, mas continua a ser um risco.

  Solução alternativa: Elimine manualmente o recurso do Zscaler antes de voltar a tentar.

• Problema 82681: Para o cliente utilizar a automação do túnel MT-GRE, quando um utilizador desliga a flag Interligação cloud a cloud (CCI) num VMware SD-WAN Gateway que está configurado para utilizar o CCI, e o utilizador desativa a flag CCI de um VMware SD-WAN Edge com CCI configurado que está a utilizar um Serviço de Segurança na Cloud Zscaler, as entradas Zscaler MT-GRE podem não ser eliminadas do Edge ou do portal Zscaler.

  Depois de um site CCI ter sido eliminado do Gateway, as entradas para este site também devem ser removidas. Este problema só foi visto durante a automação de teste e não foi reproduzido manualmente, mas continua a ser um risco.

  Solução alternativa: Elimine manualmente o recurso do Zscaler antes de voltar a tentar.

• Problema 103769: um operador pode verificar que um VMware SASE Orchestrator numa implementação de grande escala está a ter problemas de desempenho, como uma utilização do disco de 100% e o facto de o Orchestrator já não acumular registos.

  Este problema ocorre devido a uma alteração no comportamento de registo no Orchestrator 5.1.0 que pode fazer com que as pastas onde são guardados os registos fiquem cheias e a CPU do Orchestrator atinja 100% de utilização. Este problema ocorre devido a uma alteração no comportamento de registo no Orchestrator 5.1.0 que pode fazer com que as pastas onde são guardados os registos fiquem cheias e a CPU do Orchestrator atinja 100% de utilização.

  Solução alternativa: um superutilizador operador tem de iniciar sessão no Orchestrator e limpar os registos pendentes.

• Problema 114475: quando um operador tenta atualizar um VMware SASE Orchestrator da versão 4.2.0 para 5.1.0, o Orchestrator pode comunicar que a atualização falhou.

  Nos registos, o Operador veria esta entrada: Erro ao inicializar o serviço do servidor CWS. Erro: Demasiadas ligações (Error while initializing CWS Server service. Error: Too many connections).

  Este problema é causado pela reinicialização do MySQL antes da instalação de vco-db-schema, o que se deve ao facto de o MySQL não definir o número máximo de ligações. Além disso, apesar de o Orchestrator comunicar que a instalação falhou, na realidade, a instalação foi concluída e o utilizador pode reiniciar o Orchestrator e todos os serviços funcionarão conforme o esperado.

• Problema 117699: um operador que tente atualizar um VMware SD-WAN Orchestrator 4.2.x para se tornar num SASE Orchestrator 5.2.0 pode observar que a atualização falha.

  A atualização não é bem sucedida e fica bloqueada em “A aguardar pelo serviço CWS...” (Waiting for the CWS service up...). Este problema limita-se aos Orchestrators 4.2.x.

  Solução alternativa: a solução alternativa para este problema é atualizar primeiro o Orchestrator 4.2.x para 4.5.1 e, em seguida, para a versão 5.2.0.0.

• Problema 124568: num VMware SASE Orchestrator implementado com uma topologia de recuperação após desastre (DR), em casos raros, o utilizador operador pode observar que a DR é interrompida, o que provoca uma falta temporária de replicação entre os Orchestrators ativos e em standby.

  A experiência do utilizador não é afetada, visto que tal é isolado apenas à DR. A página DR indicará um estado de erro em vez de STANDBY_RUNNING.

  Solução alternativa: trata-se de um erro intermitente e irá recuperar automaticamente.

• Problema 125006: num VMware SASE Orchestrator configurado com uma topologia de recuperação após desastre (DR), a base de dados do Orchestrator pode falhar e isso leva o Orchestrator em standby a entrar num estado de erro e, em casos raros, pode fazer com que os Edges e os Gateways apareçam como offline na IU do Orchestrator e acionem eventos e alertas.

  Espera-se que o estado da base de dados seja recuperado automaticamente dentro de alguns minutos e os Orchestrators DR sejam ressincronizados. No entanto, às vezes, este estado pode exceder o período de tolerância e tanto os Edges como os Gateways começam a enviar os respetivos heartbeats para o Orchestrator em standby em vez do Orchestrator ativo. Como tal, o Orchestrator ativo marca os Edges e os Gateways que não enviam heartbeats como inativos e aciona eventos e alertas. Este problema é puramente do lado da gestão e não afeta o tráfego de rede.

  Solução alternativa: a forma de evitar este problema sem correção é aumentar a propriedade do sistema do Orchestrator que controla a tolerância para uma sincronização com falha: vco.disasterRecovery.transientErrorToleranceSecs numa quantidade adequada para fornecer uma janela de recuperação automática mais longa.

• Problema 125082: se um utilizador configurar um VMware SD-WAN Edge com um endereço IP do Servidor DNS sobreposto numa VLAN e, em seguida, alterar uma definição da interface no perfil que o Edge está a utilizar, o endereço IP do Servidor DNS deixará de estar presente para a VLAN do Edge.

  A nova IU não envia o sinalizador de sobreposição na secção DHCP e isso faz com que qualquer alteração de perfil acione uma sobreposição da secção DHCP.

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

• Problema 125504: se um caminho estático for configurado com o próximo hop como uma VLAN com endereço IPv4/IPv6 ao nível do perfil e, em seguida, substituído ao nível do Edge e adicionar um endereço IPv4/IPv6 à VLAN, o caminho estático não será marcado como N/D e o VMware SASE Orchestrator solicitará a interface num menu pendente.

  O comportamento esperado é que, quando um caminho estático configurado com um próximo hop como uma VLAN com endereço IPv4/IPv6, o Orchestrator não solicita a interface e o caminho é marcado como N/D.

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

• Problema 125663: um utilizador pode configurar o mesmo endereço IP IPv4/IPv6 para várias interfaces do Edge.

  O VMware SASE Orchestrator está a permitir que um utilizador configure o mesmo IP em várias interfaces WAN, LAN ou subinterfaces.

  Solução alternativa: não há uma solução para este problema além de garantir que não está a configurar o mesmo endereço IP para várias interfaces.

• Problema 126421: para parceiros que utilizam um Gateway de parceiro, ao configurar os Detalhes de entrega (Hand Off Details), a opção “Utilizar para túneis privados” (Use for Private Tunnels) está sempre marcada, independentemente do que o utilizador fizer.

  Não se trata de um problema cosmético, pois o Orchestrator aplicará a configuração Utilização para túneis privados (Use for Private Tunnels) ao handoff do Gateway de parceiro, o que poderá afetar o tráfego do cliente que utiliza o Gateway de parceiro.

  Solução alternativa: não há uma solução para este problema num Orchestrator com apenas uma nova interface de utilizador.

• Problema 126425: ao consultar a página Configurar > Dispositivo > Routing e NAT (Configure > Device > Routing & NAT) ao nível do perfil, o botão de alternar Ligar/Desligar do OSPF ( OSPF On/Off) está em falta.

  O botão de alternar Ativa/Desativar OSPF (OSPF On/Off) não foi migrado para a nova IU ao nível do perfil e só é apresentado ao nível do Edge.

  Solução alternativa: não há uma solução para este problema num Orchestrator com apenas uma nova interface de utilizador.

• Problema 126465: a IU do VMware SASE Orchestrator não está a aplicar as alterações feitas por um utilizador para criar um cluster Edge.

  Se um utilizador aceder à secção Configurar > Edge > Alta disponibilidade (Configure > Edge > High Availability) da IU e ativar a HA com um tipo de cluster e criar um cluster de Hub com o nome xxxx e guardar as alterações, o utilizador observará que a opção de cluster depois de guardar não estará selecionada na secção HA e o cluster de Hub criado com o nome xxxx não estará presente.

  Solução alternativa: não há uma solução para este problema num Orchestrator com apenas uma nova interface de utilizador.

• Problema 126695: se um utilizador estiver a configurar webhooks para alertas, quando clicar no botão “Configurar modelo de carga útil” (Configure Payload Template), o menu não será apresentado.

  Este problema ocorre ao configurar webhooks na página SD-WAN > Definições > Alertas > Webhooks (SD-WAN > Settings > Alerts > Webhooks) da IU. Ao consultar a consola do browser, um utilizador também poderia ver a mensagem: ERROR TypeError: Cannot read properties of undefined (reading 'invalid').

  Solução alternativa: não há uma solução para este problema num Orchestrator com apenas uma nova interface de utilizador.

• Problema 127152: os utilizadores não conseguem guardar interfaces modificadas com configurações OSPF na IU do VMware SASE Orchestrator.

  Ao nível do perfil, ao configurar o OSPFv2 ou o OSPFv3, a caixa de diálogo Editar interface (Edit Interface) fica inválida após a alteração dos dados do OSPF.

  Solução alternativa: num Orchestrator sem uma correção para este problema, um utilizador teria de ativar a Autenticação MD5 e alterar a ID de chave para qualquer número de 1 a 255 e, em seguida, desativar a Autenticação MD5.

• Problema 130115: num VMware SASE Orchestrator configurado com uma topologia de recuperação após desastre (DR), as páginas de recuperação após desastre do Orchestrator ativo e em standby mostram detalhes diferentes na seção Histórico (History).

  O utilizador vê linhas adicionais para um estado DR com falha no Orchestrator ativo em comparação com as linhas em standby na seção Histórico (History) e essas linhas não são classificadas por tempo no Orchestrator ativo.