Notes de mise à jour de VMware SASE 5.2.0

VMware SASE 5.2.0 | 23 décembre 2023 VMware SASE™ Orchestrator version R5204-20230831-GA VMware SD-WAN™ Gateway version R5202-20230725-GA VMware SD-WAN™ Edge version R5202-20231107-GA-125647 Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

• Utilisation recommandée
• Compatibilité
• Chemins de mise à niveau pour Orchestrator, Gateway et Edge
• Nouvelles fonctionnalités de SD-WAN
• Nouvelles améliorations de SD-WAN
• Remarques importantes
• Langues disponibles
• Modifications de l'API Orchestrator
• Historique de révision du document

Utilisation recommandée

Cette version est recommandée pour tous les clients qui ont besoin des fonctionnalités préalablement mises à disposition dans la version 5.2.0.

Compatibilité

Les instances d'Orchestrator, les passerelles Gateway et les dispositifs Edge du Hub de version 5.2.0 prennent en charge toutes les versions précédentes du dispositif VMware SD-WAN Edge supérieures ou égales à la version 4.2.0.

Les combinaisons d'interopérabilité de SD-WAN suivantes ont été explicitement testées :

Orchestrator	Gateway	Dispositif Edge
		Hub	Site distant/Spoke
5.2.0	4.2.1	4.2.2	4.2.2
5.2.0	5.2.0	4.2.2	4.2.2
5.2.0	5.2.0	5.2.0	4.2.2
5.2.0	5.2.0	4.2.2	5.2.0
5.2.0	4.3.1	4.3.1	4.3.1
5.2.0	5.2.0	4.3.1	4.3.1
5.2.0	5.2.0	5.2.0	4.3.1
5.2.0	5.2.0	4.3.1	5.2.0
5.2.0	4.3.2	4.3.2	4.3.2
5.2.0	5.2.0	4.3.2	4.3.2
5.2.0	5.2.0	5.2.0	4.3.2
5.2.0	5.2.0	4.3.2	5.2.0
5.2.0	4.5.1	4.5.1	4.5.1
5.2.0	5.2.0	4.5.1	4.5.1
5.2.0	5.2.0	5.2.0	4.5.1
5.2.0	5.2.0	4.5.1	5.2.0
5.2.0	5.0.1.2	5.0.1.2	5.0.1.2
5.2.0	5.2.0	5.0.1.2	5.0.1.2
5.2.0	5.2.0	5.2.0	5.0.1.2
5.2.0	5.2.0	5.0.1.2	5.2.0
5.2.0	5.1.0	5.1.0	5.1.0
5.2.0	5.2.0	5.1.0	5.1.0
5.2.0	5.2.0	5.2.0	5.1.0
5.2.0	5.2.0	5.1.0	5.2.0
5.2.0	5.2.0	5.2.0	5.2.0

Note:

la table ci-dessus n'est entièrement valide que pour les clients utilisant des services SD-WAN. Les clients nécessitant un accès à VMware Cloud Web Security ou à VMware Secure Access doivent mettre à niveau leurs dispositifs Edge vers la version 4.5.0 ou une version ultérieure.

Important:

VMware SD-WAN version 4.0.x a atteint la fin du support. Les versions 4.2.x et 4.3.x ont atteint la fin du support pour les passerelles Gateway et les dispositifs Orchestrator. La version 4.5.x approche de la fin du support pour les passerelles Gateway et les dispositifs Orchestrator.

• La version 4.0.x a atteint la fin du support général (EOGS, End of General Support) le 30 septembre 2022 et la fin de l'assistance technique (EOTG, End of Technical Guidance) le 31 décembre 2022. 

• La version 4.2.x des dispositifs Orchestrator et des passerelles Gateway a atteint la fin du support général (EOGS) le 30 décembre 2022 et la fin de l'assistance technique (EOTG) le 30 mars 2023.

• La version 4.2.x des dispositifs Edge a atteint la fin du support général (EOGS) le 30 juin 2023 et atteindra la fin de l'assistance technique (EOTG) le 30 septembre 2025.

• La version 4.3.x des dispositifs Orchestrator et des passerelles Gateway a atteint la fin du support général (EOGS) le 30 juin 2023 et la fin de l'assistance technique (EOTG) le 30 septembre 2023.

• La version 4.3.x des dispositifs Edge a atteint la fin du support général (EOGS) le 30 juin 2023 et atteindra la fin de l'assistance technique (EOTG) le 30 septembre 2025.

• La version 4.5.x des dispositifs Orchestrator et des passerelles Gateway a atteint la fin du support général (EOGS) le 30 septembre 2023 et atteindra la fin de l'assistance technique (EOTG) le 31 décembre 2023.

• Pour plus d'informations, consultez l'article de la base de connaissances : Annonce : Fin de la durée de vie du support de VMware SD-WAN version 4.x (88319).

Chemins de mise à niveau pour Orchestrator, Gateway et Edge

La liste suivante répertorie les chemins des clients souhaitant mettre à niveau Orchestrator, Gateway ou Edge d'une version antérieure vers la version 5.2.0.

Orchestrator

Les instances d'Orchestrator utilisant la version 4.2.0 ou une version ultérieure peuvent être mises à niveau vers la version 5.2.0. 

Gateway

La mise à niveau d'une passerelle Gateway utilisant la version 4.2.0 ou ultérieure vers la version 5.2.0 est entièrement prise en charge pour tous les types de passerelles.

Important:

lors du déploiement d'une nouvelle passerelle Gateway à l'aide de la version 5.2.0, l'instance de VMware ESXi doit être au moins de version 6.7, Update 3 jusqu'à la version 7.0. L'utilisation d'une instance d'ESXi antérieure entraîne l'échec du service de plan de données de la passerelle Gateway lors de la tentative d'exécution de la version 5.2.0 ou ultérieure.

Important:

avant la mise à niveau d'une passerelle Gateway vers la version 5.2.0, l'instance d'ESXi doit être mise à niveau vers au moins la version 6.7, Update 3 jusqu'à la version 7.0. L'utilisation d'une instance d'ESXi antérieure entraîne l'échec du service de plan de données de la passerelle Gateway lors de la tentative d'exécution de la version 5.2.0 ou ultérieure.

Dispositif Edge

Vous pouvez mettre à niveau un dispositif Edge directement vers la version 5.2.0 à partir de n'importe quelle version 4.x ou ultérieure.

Nouvelles fonctionnalités de SD-WAN

Qualité d'expérience (QoE) personnalisable pour la latence

Auparavant, les valeurs de latence des liens à latence élevée (par exemple, les liens par satellite ou les liens LTE) étaient statiques. Par conséquent, la page QoE affichait un graphique rouge pour la latence et la qualité globale, le service SD-WAN excluait ainsi ce lien du processus de sélection des liens, même si les partenaires et les clients souhaitaient prendre en compte le lien à latence élevée.

Dans la version 5.2.0, les utilisateurs ont la possibilité de modifier les valeurs de seuil de latence pour les types de trafic vidéo, vocal et transactionnel via la fonctionnalité QoE personnalisable (Customizable QoE). Les clients peuvent ainsi inclure des liens à latence élevée dans le cadre du processus de sélection et Orchestrator applique les nouvelles valeurs à la page de surveillance QoE.

Contrôle d'entreprise pour la visibilité des liens inactifs sur la page Surveiller (Monitor) > Présentation du réseau (Network Overview)

Auparavant, un client ne disposait d'aucun contrôle sur la durée pendant laquelle Orchestrator affichait un lien WAN inactif sur la page Surveiller (Monitor) > Présentation du réseau (Network Overview). Si un lien WAN était inactif en permanence pendant au moins 24 heures, Orchestrator cessait d'afficher ce lien WAN et la visibilité était perdue tant que le lien restait inactif. Avec la version 5.2.0, un client a la possibilité de configurer un paramètre de temps personnalisé pouvant aller jusqu'à 365 jours continus avant qu'Orchestrator cesse d'afficher un lien WAN inactif. Un client configure ce paramètre avec Paramètres de service (Service Settings) > Gestion d'Edge (Edge Management) > Limite de lien du dispositif Edge inactif (Edge Link Down Limit).

Prise en charge de GRE/BGP sur l'interface LAN

Les dispositifs Edge d'une instance de Virtual Private Cloud (VPC) de transit peuvent utiliser Generic Routing Encapsulation (GRE)/BGP et l'attachement Connect pour se connecter à une instance d'AWS Transit Gateway (TGW). L'attachement Connect et le peer Connect sont tous deux configurés sur un attachement VPC à TGW. GRE utilise une adresse IP privée attribuée sur une interface LAN routée (non-WAN) avec la configuration de deux BGP Neighbors sur le tunnel GRE.

Résumé des routes

Le résumé des routes (également appelé agrégation de routes ou super-réseaux) résout les limitations d'échelle des périphériques SD-WAN en réduisant le nombre de routes qu'un routeur annonce à un neighbor en consolidant les préfixes de routes sélectionnés en une annonce de route unique.

Lors de l'utilisation de BGP, le client configure cette fonctionnalité sous Paramètres avancés (Advanced Settings). Lors de l'utilisation d'OSPF, le client configure le résumé des routes sur la page de configuration principale.

Note:

Orchestrator, les passerelles Gateway et les dispositifs Edge doivent tous être mis à niveau vers la version 5.2.0 ou une version ultérieure pour utiliser la fonctionnalité Résumé des routes (Route Summarization).

Routage à réparation spontanée

Dans les grands déploiements basés sur un centre de données impliquant des Hubs et des clusters, il existe un risque d'interruptions du trafic en raison de routes manquantes. Avant la version 5.2.0, l'équipe d'ingénierie ou le support VMware devaient restaurer ces routes manquantes via une action qui était elle-même perturbatrice. VMware SD-WAN ajoute la fonctionnalité de routage à réparation spontanée pour réduire le risque de problèmes de routes manquantes dans les déploiements de centre de données en raison de problèmes de synchronisation.

Le routage à réparation spontanée est mis en œuvre comme un mécanisme d'audit dans lequel la passerelle compare le nombre de routes sur les dispositifs Spoke Edge avec les dispositifs Edge de centre de données du Hub/cluster et déclenche automatiquement une resynchronisation des routes lorsque la différence entre les spokes et les sites du centre de données dépasse un seuil par défaut. Cette fonctionnalité est implémentée automatiquement pour tous les déploiements de la version 5.2.0 (Orchestrator, Gateway et Edge utilisant la version 5.2.0) et aucune configuration n'est requise.

Bascule automatique de la carte SIM

Alors que le dispositif Edge 610-LTE prend en charge le DSSS (Dual SIM Single Standby), le client doit passer manuellement de la carte SIM active à la carte SIM passive via Orchestrator. Dans la version 5.2.0, le client a la possibilité d'utiliser Bascule automatique (Automatic Switchover) pour un dispositif Edge 610-LTE.

Lorsqu'un client configure la bascule automatique, le dispositif Edge 610-LTE détecte automatiquement si la connexion LTE principale a échoué et initie une connexion avec la carte SIM passive. La fonctionnalité inclut un temporisateur de bascule configurable afin qu'un client puisse spécifier la durée d'attente du dispositif Edge avant de basculer sur la carte SIM passive. La page Surveiller (Monitor) > Dispositifs Edge (Edges) > Présentation (Overview) > État des liens (Links Status) ajoute une nouvelle colonne Carte SIM en mode double automatique (Auto Dual-Mode SIM) qui inclut les détails de bascule de la carte SIM.

Note:

La bascule automatique est disponible uniquement pour les modèles Edge 610-LTE. Cette fonctionnalité n'est pas disponible pour les modèles Edge 510-LTE.

Module de plate-forme sécurisée (TPM)

Le module de plate-forme sécurisée (TPM) est une fonctionnalité de sécurité basée sur le matériel. Il fournit une zone de stockage sécurisée pour les informations sensibles telles que les clés de chiffrement, les mots de passe et les certificats avec une couche de protection physique via un « coffre matériel » unidirectionnel.

VMware inclut le TPM sur toutes les variations (LTE, -N, etc.) des dispositifs matériels SD-WAN Edge (510, 520, 540, 610, 620, 640, 680, 3000, 3100, 3400, et 3800). Un client active la fonctionnalité via l'interface utilisateur d'Orchestrator en accédant à Configurer (Configure) > Présentation (Overview) et en cochant la case Chiffrer les secrets du périphérique (Encrypt Device Secrets).

Note:

Les dispositifs Edge virtuels ne prennent actuellement pas en charge le TPM.

Contrôle d'accès Wi-Fi à l'aide du filtrage MAC

Un client peut utiliser le contrôle d'accès Wi-Fi comme couche supplémentaire de sécurité pour les réseaux sans fil. Lorsqu'il est activé, SD-WAN autorise uniquement les adresses MAC connues et approuvées à associer à la station de base.

Nouvelles améliorations de SD-WAN

État des neighbors de passerelles BGP (BGP Gateway Neighbor State)

Auparavant, Orchestrator ne marquait pas correctement l'état du BGP Neighborship si le dispositif Edge était déconnecté en raison d'une perte de puissance, car il continuait à utiliser l'état antérieur. Dans la version 5.2.0, Orchestrator marque correctement l'état du BGP Neighborship, comme « INDISPONIBLE » (UNAVAILABLE) dans ce scénario.

Service de pare-feu amélioré

Le nouveau service de pare-feu amélioré est une fonction de pare-feu avancée intégrée au dispositif SD-WAN Edge. VMware l'a conçu pour protéger les réseaux de sites distants d'une organisation contre les cybermenaces modernes et sophistiquées, renforçant ainsi la sécurité. Un client peut obtenir le service de pare-feu amélioré via une licence de module complémentaire pour VMware SD-WAN. Il est pris en charge sur tous les modèles de dispositifs SD-WAN Edge (matériels et virtuels).

La version initiale du service de pare-feu amélioré dans la version 5.2.0 présente les éléments suivants :

• La fonctionnalité Système de détection des intrusions/système de prévention des intrusions (IDS/IPS) (Intrusion Detection System/Intrusion Prevention System [IDS/IPS]) optimisée par les composants de sécurité VMware NSX primés de VMware et inclut la prise en charge du trafic chiffré et non chiffré. En combinant la puissance de la sécurité NSX aux plates-formes VMware SD-WAN Edge, les clients peuvent éliminer en toute confiance les pare-feu hérités au niveau du site distant sans sacrifier la sécurité et bénéficier d'opérations de réseau et de sécurité simplifiées, tout en tirant parti de l'investissement de VMware dans les renseignements sur les menaces.

• La fonctionnalité Journalisation du pare-feu Edge hébergée par VMware (VMware Hosted Edge Firewall Logging) fournit un stockage de journaux hébergés pour collecter des journaux de pare-feu et de menaces (règles d'autorisation et de refus) à partir des dispositifs Edge. Dans sa publication initiale de la version 5.2.0, Orchestrator conserve par défaut 15 Go de journaux ou sept jours de journalisation (selon l'échéance la plus proche) par locataire client, après quoi ceux-ci sont remplacés. Ce service est inclus avec une licence VMware SD-WAN valide. Une version ultérieure ajoutera l'option d'achat de rétention prolongée des journaux.

Autorité de certification externe

Dans la phase 3 de la mise en œuvre de l'autorité de certification externe, l'interface utilisateur d'Orchestrator version 5.2.0 inclut la prise en charge d'une autorité de certification intermédiaire.

Journaux de pare-feu sur Orchestrator

Auparavant, le seul moyen pour un client de stocker et d'afficher les journaux de pare-feu consistait à les transférer vers un serveur Syslog. Dans la version 5.2.0, le client peut stocker les journaux de pare-feu sur Orchestrator et effectuer des opérations d'affichage, de tri et de recherche sur ces journaux dans l'interface utilisateur d'Orchestrator. Pour plus d'informations, reportez-vous aux sections Configurer le pare-feu de profil, Configurer le pare-feu du dispositif Edge et Surveiller les journaux de pare-feu.

Améliorations de la haute disponibilité

La version 5.2.0 inclut plusieurs améliorations pour un site déployé à l'aide d'une topologie à haute disponibilité avec une paire de dispositifs Edge. Celles-ci incluent les éléments suivants :

• La fonctionnalité Stabilité HA améliorée (Improved HA Stability) permet de s'assurer qu'un site HA subit moins de basculements inutiles ou d'états « Split Brain » en mode actif-actif.

• Événements

  • Nouveaux événements générés pour les modifications d'état des liens WAN, LAN et HA.

  • L'utilité des événements est améliorée avec des métadonnées supplémentaires, telles que le numéro de série et le mode HA.

• Surveillance

  • L'onglet HA passif (HA Standby) est un nouveau tableau de bord permettant au dispositif Edge passif de signaler l'utilisation du CPU et de la mémoire se trouvant sur la page Surveiller (Monitor) > Dispositifs Edge (Edges).

  • Pour tous les tableaux de bord Surveiller (Monitor) > Dispositifs Edge (Edges), il existe désormais des « barres de basculement ». Il s'agit de marqueurs verticaux sur les graphiques indiquant où et quand un basculement HA s'est produit.

  • Tous les graphiques Surveiller (Monitor) > Dispositifs Edge (Edges) incluent une zone avec le numéro de série du dispositif Edge HA afin qu'un client sache rapidement quel dispositif Edge HA est actif pendant une période spécifique sur un graphique de surveillance.

• Nouvelles options de configuration pour la haute disponibilité

  • La fonctionnalité Multiplicateur de temps de détection de basculement HA (HA Failover Detection Time Multiplier) est utilisée pour définir un seuil de haute disponibilité plus long. Le temporisateur représente la durée pendant laquelle un dispositif Edge passif attend un paquet de pulsations du dispositif Edge actif avant de s'activer. Dans certains scénarios, il peut empêcher un état « Split Brain » actif-actif de se trouver sur un dispositif Edge HA soumis sous une charge de trafic élevée.

  • La fonctionnalité Interface HA configurable (Configurable HA Interface) permet au client de configurer n'importe quel port commuté du dispositif Edge à utiliser comme interface HA (qui connecte les dispositifs Edge actif et en veille pour la synchronisation). Auparavant, SD-WAN limitait l'interface HA à une interface par défaut pour ce modèle d'Edge (c'est-à-dire, LAN1 ou GE1).

  • Le choix par le client d'un port SFP 1G/10G comme interface HA constitue une amélioration supplémentaire de l'interface HA configurable (Configurable HA Interface).

• Capture de paquets pour l'interface HA du dispositif Edge passif (Packet Capture for the Standby Edge's HA Interface) : un administrateur dispose désormais d'un outil de dépannage HA supplémentaire avec la possibilité de demander une capture de paquets de l'interface HA du dispositif Edge passif.

Prise en charge de la mise à niveau de la haute disponibilité pour le microprogramme de la plate-forme ou l'image d'usine

Auparavant, la mise à niveau du microprogramme de la plate-forme ou de l'image d'usine pour un site HA était une tâche longue et perturbatrice qui devait être effectuée manuellement par un utilisateur. Lorsqu'un profil d'opérateur est appliqué à un site HA avec un nouveau microprogramme de la plate-forme ou une nouvelle image d'usine, un dispositif Orchestrator de version 5.2.0 peut automatiquement mettre à jour l'image d'usine et le microprogramme de la plate-forme sur la haute disponibilité pour les dispositifs SD-WAN Edge, comme il le faisait auparavant pour le logiciel Edge HA.

Améliorations d'IPv6

La version 5.2.0 inclut les améliorations d'IPv6 suivantes :

• OSPFv3

  • Apprentissage des routes IPv6 d'underlay.

  • Redistribution des routes OSPFv3 dans l'overlay/le BGP et vice-versa.

  • Prise en charge d'Overlay Flow Control (OFC).

  • Suite complète de diagnostics à distance OSPFv3.

• Prise en charge de l'agent relais DHCPv6 sur Edge

  • Cas d'utilisation du serveur DHCP local/distant/cloud

  • Agit comme plusieurs agents relais

• Destinations non-SD-WAN via un dispositif Edge (IPv6)

  • Scénarios de basculement de tunnel pris en charge :

    • Actif-Actif

    • Actif-Passif

    • Actif-Passif à chaud

  • Sélection de liens basée sur les flux.

  • L'interface utilisateur d'Orchestrator inclut la surveillance des tunnels, les événements et les alertes.

Contournement d'adresse MAC (MAB) RADIUS pour 802.1x sur les VLAN

Dans la version 5.1.0, le MAB RADIUS pour 802.1x a été ajouté, mais est limité aux interfaces routées uniquement. Dans la version 5.2.0, les clients peuvent également utiliser cette fonctionnalité pour les VLAN qui peuvent être attribués au port commuté d'un dispositif Edge.

Note:

La fonctionnalité MAB présente les limitations suivantes lorsqu'elle est configurée pour un VLAN à utiliser sur un port commuté :

• Le trafic L2 ne déclenche pas le MAB RADIUS.

• Le trafic L2 n'est pas transféré sur les commutateurs basés sur Linux tant que le trafic routé n'est pas visible. Les commutateurs matériels ne filtrent déjà pas le trafic L2 pur et cette limitation reste inchangée.

• Si aucun trafic routé n'est observé et que le MAB RADIUS expire (la valeur par défaut est de 30 minutes), le trafic L2 est à nouveau bloqué.

• Des hooks supplémentaires pour vérifier l'état 802.1x des paquets à destination automatique peuvent entraîner une dégradation des performances lorsque 802.1x est activé.

• Le trafic destiné à être autogéré et entièrement géré par Linux n'est plus filtré avant l'authentification 802.1x (DHCP, DNS, SSH, etc.).

Améliorations de la visibilité des routes pour les passerelles

Ces améliorations répondent au besoin des clients et des partenaires de disposer d'une plus grande visibilité sur la table de routage d'une passerelle et incluent les éléments suivants :

• Onglet Table de routage de la passerelle (Gateway Route Table) sur la page Surveiller (Monitor) > Routage (Routing) d'Orchestrator.

• Onglet État des neighbors de passerelles BGP (BGP Gateway Neighbor State) sur la page Surveiller (Monitor) > Routage (Routing) pour afficher les routes BGP annoncées et reçues par neighbor.

• Renseignez les informations d'un préfixe de route spécifique.

• Filtrage basé sur un préfixe de route.

• Option permettant d'exporter la table de routage de la passerelle.

Module de plate-forme sécurisée (TPM)

Le module de plate-forme sécurisée (TPM) est une fonctionnalité de sécurité basée sur le matériel. Il fournit une zone de stockage sécurisée pour les informations sensibles telles que les clés de chiffrement, les mots de passe et les certificats avec une couche de protection physique via un « coffre matériel » unidirectionnel.

VMware SD-WAN inclut le TPM sur toutes les variantes (LTE, -N, etc.) des dispositifs SD-WAN Edge matériels (510, 520, 540, 610, 620, 640, 680, 3000, 3100, 3400 et 3800). Un client active la fonctionnalité via l'interface utilisateur d'Orchestrator en accédant à Configurer (Configure) > Présentation (Overview) et en cochant la case Chiffrer les secrets du périphérique (Encrypt Device Secrets).

Note:

Les dispositifs Edge virtuels ne prennent pas en charge TPM dans cette version.

Remarques importantes

Build d'interface utilisateur

À partir de la version 5.2.0.4 d'Orchestrator, VMware introduit une build d'interface utilisateur. Une build d'interface utilisateur contient uniquement des correctifs aux problèmes qui affectent la façon dont vous utilisez l'interface utilisateur d'Orchestrator. Contrairement à une build standard d'Orchestrator, une build d'interface utilisateur n'inclut aucun correctif pour les problèmes de plan de gestion/contrôle qui affectent le fonctionnement sous-jacent d'Orchestrator.

Une build d'interface utilisateur est ajoutée à une version d'Orchestrator existante et possède une version de build unique qui est répertoriée sous le nom de la build d'Orchestrator. La build d'interface utilisateur se trouve au même endroit que la version d'Orchestrator. Pour y accéder, cliquez sur l'icône ? dans le coin supérieur droit de l'écran de l'interface utilisateur d'Orchestrator. Par exemple, si un dispositif Orchestrator exécutant la version 5.2.0.4 avec la build R5204-20230831-GA est mis à jour avec la build d'interface utilisateur version R5204-20230914-GA, celle-ci s'affiche immédiatement sous la build d'Orchestrator avec la mention Build d'interface utilisateur (UI Build). Si un dispositif Orchestrator ne dispose pas d'une build d'interface utilisateur, un utilisateur voit uniquement la build d'Orchestrator.

Pour mettre à niveau des dispositifs Orchestrator avec une build d'interface utilisateur, la procédure est la suivante :

• L'équipe responsable des opérations de VMware met à niveau les dispositifs Orchestrator partagés hébergés et les dispositifs Orchestrator privés hébergés avec la dernière build d'interface utilisateur dans la semaine suivant la publication de la build si les dispositifs Orchestrator utilisent déjà la version d'Orchestrator la plus récente.

• Un partenaire utilisant un dispositif Orchestrator dédié doit ouvrir un ticket de support pour que l'équipe responsable des opérations mette à niveau son dispositif Orchestrator avec une build d'interface utilisateur, à condition que le dispositif utilise la version d'Orchestrator la plus récente.

Note:

Les builds d'interface utilisateur ne sont pas disponibles pour les clients qui déploient un dispositif Orchestrator sur site.

Pour plus d'informations sur la build d'interface utilisateur, reportez-vous aux articles de la base de connaissances FAQ sur les mises à niveau logicielles pour VMware SD-WAN (67152) et Types de versions logicielles et stratégie de mise à niveau logicielle pour les dispositifs Orchestrator et les passerelles Gateway VMware SD-WAN (89609).

Modification du comportement de la NAT côté LAN

Lorsqu'une NAT côté LAN est configurée pour des traductions plusieurs-à-un à l'aide de la traduction d'adresses de port (PAT, Port Address Translation), le trafic initié en sens contraire peut autoriser un accès inattendu à des adresses fixes basées sur le masque externe et l'adresse IP d'origine. Ce nouveau comportement s'applique aux règles NAT de destination (DNAT), NAT source (SNAT) et NAT source et de destination (S+D NAT).

Par exemple, une règle SNAT avec un réseau interne 192.168.1.0/24 et une adresse externe 10.1.1.100/32 autorise la traduction de l'extérieur vers l'intérieur 192.168.1.100.

Pour résoudre ce nouveau comportement. SD-WAN bloque désormais le trafic lorsqu'une connexion est établie dans le sens PAT inverse.

Pour restaurer le comportement d'origine, un utilisateur doit configurer deux règles du même type que la règle d'origine (SNAT, DNAT, S+D NAT) dans un ordre particulier. Par exemple, à l'aide du scénario SNAT précédent, un utilisateur doit configurer les éléments suivants :

1. Règle SNAT avec un réseau interne 192.168.1.100/32 et une adresse externe 10.1.1.100/32

2. Règle SNAT avec un réseau interne 192.168.1.0/24 et une adresse externe 10.1.1.100/32

Si la règle d'origine est une DNAT ou une S+D NAT, l'utilisateur a besoin de deux règles DNAT ou S+D NAT avec la même structure et le même ordre.

Dans la version 4.5.0 et les versions ultérieures, un utilisateur peut déterminer si les flux sont abandonnés pour ce type de trafic dans les journaux dispcnt d'un bundle de diagnostics en recherchant le compteur lan_side_nat_reverse_pat_drop.

Interface utilisateur classique obsolète sur SASE Orchestrator

Dans la version 5.2.0, la nouvelle interface utilisateur est désormais terminée pour toutes les tâches de configuration et de surveillance. Par conséquent, l'interface utilisateur classique est masquée par défaut et n'est pas disponible pour utilisation. En outre, l'équipe d'ingénierie SASE ne corrigera plus les problèmes spécifiques à l'interface utilisateur classique.

Les nouveaux clients directs sur un dispositif Orchestrator hébergé sont automatiquement attribués à la plate-forme Cloud Services (CSP) en tant que fournisseur d'identité

Les nouveaux clients directs (non attribués à un partenaire) qui sont créés sur un dispositif Orchestrator hébergé de version 5.2.0 sont automatiquement configurés pour SSO à l'aide de CSP comme fournisseur d'identité. En conséquence :

• Les nouveaux administrateurs sont créés par un administrateur disposant d'un rôle de super utilisateur via le portail CSP.

• En cas de panne de CSP, le client est autorisé à utiliser un compte d'administrateur « d'accès d'urgence » avec une authentification locale (nom d'utilisateur/mot de passe) pour lui permettre d'accéder à son portail.

• Les nouveaux clients directs devront utiliser l'authentification par jeton pour l'accès aux API. Ils ne pourront pas utiliser l'authentification basée sur les cookies lorsque la création d'utilisateurs est déplacée vers CSP.

Note:

Les instances d'Orchestrator sur site ne sont pas soumises aux exigences de CSP et leurs clients continueront à utiliser l'authentification basée sur Orchestrator.

L'interconnexion du Hub ou du cluster reste à accès en avant-première

L'interconnexion du Hub ou du cluster a été ajoutée dans la version 5.1.0 avec la mise en garde :

« L'activation de la fonctionnalité Interconnexion du Hub ou du cluster ajoute une modification fondamentale du protocole de routage de VMware SD-WAN dans lequel il permet aux paquets de traverser plusieurs tronçons du réseau. Lorsque cette modification a été testée dans des topologies représentatives, il n'est pas possible de tester tous les scénarios de routage qui peuvent être rencontrés lors d'une modification permettant la distribution de routes distantes. Par conséquent, VMware publie cette fonctionnalité comme accès en avant-première et surveille étroitement tout comportement de routage inattendu pour les déploiements dans lesquels elle est activée. »

La mise en garde reste en vigueur pour cette fonctionnalité dans la version 5.2.0.

Limitation avec BGP sur IPsec dans Edge et Gateway, et l'automatisation d'Azure Virtual WAN

La fonctionnalité BGP sur IPsec dans Edge et Gateway n'est pas compatible avec et l'automatisation d'Azure Virtual WAN à partir du dispositif Edge ou Gateway. Seules les routes statiques sont prises en charge lors de l'automatisation de la connectivité entre un dispositif Edge ou Gateway et une instance d'Azure vWAN.

Limitation lors de la désactivation de la négociation automatique sur les modèles de dispositifs VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 et 3810

Lorsqu'un utilisateur désactive la négociation automatique pour coder en dur le débit et le duplex sur les ports GE1 - GE4 sur un modèle de dispositif VMware SD-WAN Edge 620, 640 ou 680, sur les ports GE3 ou GE4 sur un dispositif Edge 3400, 3800 ou 3810, ou sur un dispositif Edge 520/540 en cas d'utilisation d'un SFP avec une interface en cuivre sur les ports SFP1 ou SFP2, il peut constater que le lien ne s'active pas même après un redémarrage. 

Cela est dû à chacun des modèles d'Edge répertoriés utilisant le contrôleur Ethernet Intel i350, qui présente une limitation selon laquelle lorsque la négociation automatique n'est pas utilisée des deux côtés de la liaison, il n'est pas en mesure de détecter dynamiquement les câbles appropriés de transmission et de réception (auto-MDIX). Si les deux côtés de la connexion transmettent et reçoivent sur les mêmes câbles, la liaison n'est pas détectée. Si le côté homologue ne prend pas non plus en charge la fonctionnalité auto-MDIX sans négociation automatique et que la liaison ne s'active pas avec un câble droit, un câble Ethernet croisé est nécessaire pour activer la liaison.

Pour plus d'informations, consultez l'article de la base de connaissances Limitation lors de la désactivation de la négociation automatique sur des modèles de dispositifs VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 et 3810 (87208).

Langues disponibles

L'instance de VMware SASE Orchestrator utilisant la version 5.2.0 est localisée dans les langues suivantes : allemand, anglais, chinois simplifié, chinois traditionnel, coréen, espagnol, français, grec, italien, japonais, portugais européen et tchèque.

Modifications de l'API Orchestrator

Modifications de l'API Orchestrator depuis la version 5.1.0

Modifications de l'API du portail VMware SASE Orchestrator (« API v1 »)

Aucune modification n'a été apportée à l'API v1 de la version 5.1.0 vers la version 5.2.0. À titre indicatif, le journal des modifications d'API complet est disponible au téléchargement sur developer.vmware.com (reportez-vous à la section « VMware SD-WAN Orchestrator API v1 »).

Modifications de VMware SASE Orchestrator API v2

Cette version ajoute la prise en charge de la configuration des modules de qualité de service (QoS) au niveau du profil et du dispositif Edge. Des API pour le renvoi des statistiques de pare-feu et des mesures NNI sont également ajoutées pour cette version.

La version 5.2.0 ajoute les nouvelles opérations d'API suivantes :

• Module QOS au niveau du profil et du dispositif Edge

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

  • PUT /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

  • PATCH /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • POST /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • PUT /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • PATCH /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

• Statistiques de pare-feu amélioré au niveau de l'entreprise et du dispositif Edge

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/firewallIdpsStats

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/firewallIdpsStats

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/firewallIdpsStats/timeSeries

• Mesures de NNI de passerelle au niveau de l'entreprise

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/nniStats

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/nniStats/timeSeries

Documentation pour les développeurs

Toute la documentation de l'API VMware SASE/SD-WAN se trouve sur le portail de documentation pour les développeurs à l'adresse https://developer.vmware.com/apis.

Historique de révision du document

22 décembre 2023. Vingt-sixième édition.

• Ajout du problème ouvert n° 131997 à la section Problèmes connus d'Orchestrator.

18 décembre 2023. Vingt-cinquième édition.

• Ajout des problèmes résolus n° 93141 et n° 95565 à la section Problèmes résolus d'Edge et de Gateway pour la build R5200-20230530-GA d'Edge/Gateway d'origine. Ces tickets ont été omis par erreur de la première édition des Notes de mise à jour.

• Ajout des problèmes ouverts n° 118501, n° 122193, n° 129232, n° 129412, n° 129662, n° 129958, n° 131299, n° 133201 et n° 133642 à la section Problèmes connus d'Orchestrator.

• Ajout des problèmes ouverts n° 125274 et n° 134374 à la section Problèmes connus liés à Edge/Gateway.

4 décembre 2023. Vingt-quatrième édition.

• Ajout d'une nouvelle build R5204-20231201-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la douzième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build d'interface utilisateur R5204-20231201-GA inclut les correctifs des problèmes d'interface utilisateur n° 126695, n° 128921, n° 129662, n° 131224, n° 131631, n° 132047, n° 132384 et n° 133008, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

• Suppression du Problème connu n° 83166, selon lequel : « Lorsqu'une passerelle VMware SD-WAN Gateway est récemment déployée avec un type de grande instance AWS c5.4x à partir du portail AWS avec l'option IPv6 sélectionnée, les routes IPv6 ou par défaut ne sont pas configurées et les tunnels de gestion AWS Gateway IPv6 ne se forment pas. » Ce problème ne sera pas résolu et la documentation de l'utilisateur ajoutera plutôt l'obligation d'utiliser uniquement le mode statique d'attribution d'adresses IPv4/IPv6 sur les interfaces d'une passerelle, car VMware SD-WAN ne prend pas en charge DHCP côté passerelle.

22 novembre 2023. Vingt-troisième édition. R5204-20231201-GA

• Ajout d'une nouvelle build R5204-20231121-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la onzième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build d'interface utilisateur R5204-20231121-GA inclut les correctifs des problèmes d'interface utilisateur n° 128017, n° 129695, n° 130810, n° 131138 et n° 132524, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

Note:

Le problème n° 131118 était précédemment répertorié comme résolu dans la build R5204-20231109-GA de l'interface utilisateur. Cependant, le problème n'était pas entièrement résolu dans cette build. C'est désormais chose faite dans cette build.

• Ajout des problèmes résolus n° 104513 et n° 106331 à la section Problèmes résolus d'Edge et de Gateway pour la build R5200-20230530-GA d'Edge/Gateway d'origine. Ces tickets ont été omis par erreur de la première édition des Notes de mise à jour.

16 novembre 2023. Vingt-deuxième édition.

• Ajout d'une nouvelle build R5204-20231115-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la dixième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build R5204-20231115-GA d'interface utilisateur inclut les correctifs des problèmes n° 123078, n° 123718, n° 128330, n° 128765 et n° 130877 d'interface utilisateur, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

14 novembre 2023. Vingt et unième édition.

• Ajout d'une nouvelle build cumulative R5202-20231107-GA-125647 d'Edge mise à jour à la section Problèmes résolus d'Edge/de Gateway. Il s'agit d'une mise à jour de la deuxième build cumulative R5202-20230725-GA d'Edge. Elle constitue la nouvelle build GA d'Edge/de Gateway par défaut pour la version 5.2.0.

• La build R5202-20231107-GA-125647 d'Edge inclut le correctif du problème n° 125647, qui est documenté dans cette section.

Important:

• Toutes les builds d'Edge précédentes de la version 5.2.0 sont déconseillées en faveur de R5202-20231107-GA-125647.

• Les clients qui effectuent une mise à niveau vers la version 5.2.0 doivent uniquement effectuer la mise à niveau vers la build R5202-20231107-GA-125647.

• Les clients qui utilisent déjà une build d'Edge de la version 5.2.0.x n'ont pas besoin de mettre à niveau leurs dispositifs Edge vers la build R5202-20231107-GA-125647.

10 novembre 2023. Vingtième édition.

• Ajout d'une nouvelle build R5204-20231109-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la neuvième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build R5204-20231109-GA d'interface utilisateur inclut les correctifs des problèmes n° 123387, n° 123640, n° 127727, n° 129584, n° 130153 et n° 131138 d'interface utilisateur, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

2 novembre 2023. Dix-neuvième édition.

• Ajout d'une nouvelle build R5204-20231101-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la huitième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build R5204-20231101-GA d'interface utilisateur inclut les correctifs des problèmes n° 123001, n° 127904 n° 128753, n° 129061, n° 129494, n° 129662, n° 129765, et n° 129894 d'interface utilisateur, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

31 octobre 2023. Dix-huitième édition.

• Révision du libellé de Problème résolu n° 110484 dans la section Problèmes résolus d'Edge/de Gateway pour indiquer clairement que ce ticket ne résout pas les symptômes répertoriés pour le ticket, mais le logiciel Edge inclut plutôt une journalisation améliorée pour aider l'équipe d'ingénierie à fournir un correctif réel pour les symptômes répertoriés.

27 octobre 2023. Dix-septième édition.

• Ajout d'une nouvelle build R5204-20231027-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la septième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build R5204-20231027-GA d'interface utilisateur inclut les correctifs des problèmes n° 125964, n° 126602, n° 127904, n° 128279, n° 128357, n° 129413 et n° 129926 d'interface utilisateur, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

20 octobre 2023. Seizième édition.

• Ajout d'une nouvelle build R5204-20231019-GA de l'interface utilisateur d'Orchestrator à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la sixième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build R5204-20231019-GA d'interface utilisateur inclut les correctifs des problèmes n° 127021, n° 128706, n° 129049, n° 129271 et n° 129560 d'interface utilisateur, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

• Ajout du problème ouvert n° 125421 à la section Problèmes connus liés à Edge/Gateway.

• Ajout du problème résolu n° 110406 à la section Problèmes résolus d'Edge et de Gateway pour la build R5200-20230530-GA d'Edge/Gateway d'origine. Ce problème a été omis par erreur de la première édition des Notes de mise à jour.

• Ajout d'une nouvelle remarque : Modification du comportement de la NAT côté LAN à la section Remarques importantes.

13 octobre 2023. Quinzième édition.

• Ajout d'une nouvelle build d'interface utilisateur d'Orchestrator, R5204-20231013-0631-GA, à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la cinquième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build R5204-20231013-0631-GA d'interface utilisateur inclut les correctifs des problèmes n° 120419, n° 127035, n° 127636, n° 127774, n° 128371, n° 128620 et n° 129253 d'interface utilisateur, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

• Ajout du problème ouvert n° 125647 à la section Problèmes connus liés à Edge/Gateway.

4 octobre 2023. Quatorzième édition.

• Ajout d'une nouvelle build d'interface utilisateur d'Orchestrator, R5204-20231003-GA, à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la quatrième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build d'interface utilisateur R5204-20231003-GA inclut les correctifs des problèmes d'interface utilisateur n° 117923, n° 123070, n° 127037, n° 128628 et n° 128667, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

28 septembre 2023. Treizième édition.

• Ajout d'une nouvelle build d'interface utilisateur d'Orchestrator, R5204-20230927-GA, à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la troisième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build d'interface utilisateur R5204-20230927-GA inclut les correctifs des problèmes d'interface utilisateur n° 126967, n° 127006, n° 127843, n° 127849, n° 127871 et n° 128277, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

• Ajout des tickets suivants à la section Problèmes connus d'Orchestrator : n° 125082, n° 125504, n° 125663, n° 126257, n° 126421, n° 126425, n° 126465, n° 126695, n° 127037, n° 127152, n° 127636 et n° 128070.

• Ajout du problème résolu n° 110484 à la section Problèmes résolus d'Edge et de Gateway pour la build R5200-20230530-GA d'Edge/Gateway d'origine. Ce problème a été omis par erreur de la première édition des Notes de mise à jour.

21 septembre 2023. Douzième édition.

• Ajout d'une nouvelle build d'interface utilisateur d'Orchestrator, R5204-20230920-GA, à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la deuxième build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build d'interface utilisateur R5204-20230920-GA inclut les correctifs des problèmes d'interface utilisateur n° 106191, n° 113254, n° 117941, n° 117993, n° 121469, n° 126503 et n° 126257, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

• Révision de l'entrée Build d'interface utilisateur dans Remarques importantes pour ajouter des informations sur la façon dont une build d'interface utilisateur est ajoutée aux quatre types de dispositifs Orchestrator : partagé hébergé, partagé privé, dédié et sur site. Cette entrée inclut une remarque indiquant que les builds d'interface utilisateur ne sont pas disponibles pour les clients utilisant des dispositifs Orchestrator sur site.

15 septembre 2023. Onzième édition.

• Ajout d'une nouvelle entrée intitulée Build d'interface utilisateur dans Remarques importantes. Une build d'interface utilisateur est un nouveau type de version logicielle d'Orchestrator qui contient uniquement des correctifs pour les problèmes d'interface utilisateur et qui est ajouté à une version existante d'Orchestrator.

• Ajout d'une nouvelle build d'interface utilisateur d'Orchestrator, R5204-20230914-GA, à la section Problèmes d'Orchestrator résolus pour R5204-20230831-GA. Il s'agit de la première build d'interface utilisateur pour la build cumulative R5204-20230831-GA d'Orchestrator.

• La build d'interface utilisateur R5204-20230914-GA inclut les correctifs des problèmes d'interface utilisateur n° 108125, n° 122918, n° 123619, n° 123927, n° 124801, n° 125309, n° 125393, n° 125710, n° 126403 et n° 127007, qui sont documentés dans un tableau distinct à l'intérieur de la section R5204-20230831-GA.

1er septembre 2023. Dixième édition.

• Ajout d'une nouvelle build cumulative R5204-20230831-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la troisième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.2.0.

• La build R5204-20230831-GA d'Orchestrator inclut les correctifs des problèmes n° 65668, n° 104775, n° 118728, n° 120398, n° 121118, n° 121526, n° 122113, n° 123002, n° 123053, n° 123150, n° 123346, n° 123551, n° 123749, n° 124073, n° 124129, n° 124273, n° 124315, n° 124778, n° 124798 et n° 125456, qui sont documentés dans cette section.

• Ajout des problèmes ouverts n° 117037 et n° 121606 à la section Problèmes connus liés à Edge/Gateway.

• Suppression du problème ouvert n° 62701 de la section Problèmes connus liés à Edge/Gateway, car ce problème a été résolu dans la version 5.1.0.

• Réorganisation de l'Historique de révision du document de manière à classer les entrées de la plus récente à la plus ancienne pour améliorer l'expérience utilisateur.

9 août 2023. Neuvième édition.

• Ajout d'une nouvelle build cumulative R5203-20230809-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la troisième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.2.0.

• La build R5203-20230809-GA d'Orchestrator inclut les correctifs des problèmes n° 121118, n° 121884, n° 122132, n° 122797, n° 123384 et n° 123609, qui sont documentés dans cette section.

• Ajout du problème résolu n° 105861 à la section Problèmes d'Orchestrator résolus pour la build R5200-20230530-GA d'Orchestrator d'origine. Ce problème a été omis par erreur de la première édition des Notes de mise à jour.

• Ajout d'une section Langues disponibles pour indiquer clairement les langues dans lesquelles VMware SASE Orchestrator 5.2.0 est localisé.

2 août 2023. Huitième édition.

• Ajout d'une nouvelle build cumulative R5202-20230729-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la deuxième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.2.0.

• La build R5202-20230729-GA d'Orchestrator inclut les correctifs des problèmes n° 116666, n° 117772, n° 117822, n° 118544, n° 118733, n° 120070, n° 120606, n° 120774, n° 121441, n° 121472, n° 121751, n° 121835, n° 121858, n° 121993, n° 122010, n° 122271, n° 122520, n° 122866 et n° 122977, qui sont documentés dans cette section.

• Ajout du problème ouvert n° 121118 à la section Problèmes connus d'Orchestrator.

31 juillet 2023. Septième édition.

• Ajout d'une nouvelle build cumulative R5202-20230725-GA d'Edge/de Gateway à la section Problèmes résolus d'Edge/de Gateway. Il s'agit de la deuxième build cumulative d'Edge/de Gateway. Elle constitue la nouvelle build GA d'Edge/de Gateway par défaut pour la version 5.2.0.

  La build R5202-20230725-GA d'Edge/de Gateway inclut les correctifs des problèmes n° 106865, n° 117775 et n° 121368, qui sont documentés dans cette section.

• Reclassement du problème résolu n° 82095 en problème ouvert et déplacement du ticket vers la section Problèmes connus d'Orchestrator.

• Ajout des problèmes ouverts n° 117314 et n° 121998 à la section Problèmes connus liés à Edge/Gateway.

• Suppression du problème ouvert n° 53359 de la section Problèmes connus liés à Edge/Gateway, car ce problème a été résolu dans une build 4.3.x.

12 juillet 2023. Sixième édition.

• Ajout des problèmes résolus n° 86994, n° 90044, n° 98223, n° 101753, n° 105433, n° 110456, n° 106123 et n° 116086 à la section Problèmes résolus d'Edge et de Gateway de la build R5200-20230530-GA d'Edge d'origine. Ces tickets ont été omis par erreur de la première édition des Notes de mise à jour.

• Ajout du problème résolu n° 114546 à la section Problèmes d'Orchestrator résolus pour la build R5200-20230530-GA d'Orchestrator d'origine. Ce problème a été omis par erreur de la première édition des Notes de mise à jour.

5 juillet 2023. Cinquième édition.

• Ajout de Journaux de pare-feu sur Orchestrator à la liste des Nouvelles améliorations de SD-WAN. Cette amélioration a été omise par erreur de la première édition des Notes de mise à jour.

• Ajout du problème résolu n° 107317 à la section Problèmes résolus d'Edge et de Gateway de la build GA d'origine.

26 juin 2023. Quatrième édition.

• Ajout d'une nouvelle build cumulative R5201-20230623-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la première build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.2.0.

• La build R5201-20230623-GA d'Orchestrator inclut les correctifs des problèmes n° 112333, n° 113254, n° 115411, n° 115624, n° 116141, n° 116790, n° 117527, n° 117800, n° 117993, n° 118071, n° 118574, n° 118673, n° 119551 et n° 119733, qui sont documentés dans cette section.

Important:

Il est fortement recommandé aux utilisateurs d'une build 5.2.0.0 pour leur dispositif Orchestrator sur site de mettre à niveau leur dispositif Orchestrator vers la version 5.2.0.1.

22 juin 2023. Troisième édition.

• Ajout d'une nouvelle build cumulative R5201-20230619-GA d'Edge/de Gateway à la section Problèmes résolus d'Edge et de Gateway. Il s'agit de la première build cumulative d'Edge/de Gateway. Elle constitue la nouvelle build GA d'Edge/de Gateway par défaut pour la version 5.2.0.

• La build R5201-20230619-GA d'Edge/de Gateway inclut les correctifs des problèmes n° 115150 et n° 117638, qui sont documentés dans cette section.

Important:

Il est fortement recommandé aux utilisateurs d'une build 5.2.0.0 pour Edge ou Gateway de mettre à niveau leurs dispositifs Edge et/ou passerelles vers la version 5.2.0.1.

7 juin 2023. Deuxième édition.

• Ajout des problèmes résolus n° 105933 et n° 109963 à la section Problèmes résolus d'Edge et de Gateway pour la build R5200-20230530-GA initiale d'Edge. Ces tickets ont été omis par erreur de la première édition des Notes de mise à jour.

31 mai 2023. Première édition.

Problèmes résolus d'Edge et de Gateway

• Résolu dans Edge version R5202-20231107-GA-125647
• Résolu dans la version R5202-20230725-GA d'Edge/de Gateway
• Résolu dans Edge/Gateway version R5201-20230619-GA
• Résolu dans la version R5200-20230530-GA d'Edge/de Gateway

Résolu dans Edge version R5202-20231107-GA-125647

La build R5202-20231107-GA-125647 d'Edge a été publiée le 13/11/2023 et constitue une mise à jour de la 2e build cumulative d'Edge pour la version 5.2.0.

Cette build d'Edge mise à jour résout un problème critique depuis la 2e build cumulative initiale d'Edge, R5202-20230725-GA.

Important:

• Toutes les builds d'Edge précédentes de la version 5.2.0 sont déconseillées en faveur de R5202-20231107-GA-125647.

• Les clients qui effectuent une mise à niveau vers la version 5.2.0 doivent uniquement effectuer la mise à niveau vers la build R5202-20231107-GA-125647.

• Les clients qui utilisent déjà une build d'Edge de la version 5.2.0.x n'ont pas besoin de mettre à niveau leurs dispositifs Edge vers la build R5202-20231107-GA-125647.

• Problème résolu 125647 : pour un site déployé avec un modèle d'Edge 520 ou 540, lorsqu'un dispositif Edge est mis à niveau vers la version 5.2.0, les utilisateurs clients connectés au dispositif Edge via un port LAN peuvent rencontrer une perte totale de connectivité.

  Le redémarrage du dispositif Edge 520/540 ne résout pas le problème et ne rétrograde pas le dispositif Edge vers une version logicielle antérieure une fois qu'il a été mis à niveau vers une version 5.2.0. Lorsque la console du dispositif Edge est désactivée dans les paramètres Sécurité du dispositif Edge (Edge Security) > Accès à la console (Console Access) sur la page de configuration Pare-feu (Firewall) d'Orchestrator (qui est la configuration par défaut des dispositifs Edge), le pilote qui gère les ports LAN1 à LAN8 du dispositif Edge 520 ou 540 ne se configure pas correctement, ce qui empêche la création de ces ports.

  Sur un dispositif Edge sans correctif pour ce problème, vous pouvez empêcher ce problème et/ou restaurer la connectivité sur les ports LAN sur un dispositif Edge affecté en procédant comme suit : accédez à Configurer (Configure) > Dispositif Edge/Profil (Edge/Profile) > Sécurité du dispositif Edge (Edge Security) et sous Accès à la console (Console Access), cliquez sur Activer (Enable), puis sur Enregistrer les modifications (Save Changes).

  

  Note:

  La modification de cette configuration nécessite un redémarrage du dispositif Edge, qui dure environ 2 à 3 minutes. Si possible, effectuez cette modification dans une fenêtre de maintenance.

Résolu dans la version R5202-20230725-GA d'Edge/de Gateway

La build R5202-20230725-GA d'Edge et de Gateway a été publiée le 31/07/2023 et constitue la 2e build cumulative d'Edge/de Gateway pour la version 5.2.0.

Cette build cumulative d'Edge/de Gateway résout les problèmes critiques ci-dessous depuis la 1re build cumulative R5201-20230619-GA d'Edge/de Gateway.

• Problème résolu 106865 : un client qui utilise le service Edge Network Intelligence et qui a activé l'analyse sur son entreprise peut observer que le trafic non-IP (par exemple, l'authentification RADIUS) est abandonné.

  Lorsque l'analyse est activée, si des trames non-IP sont reçues sur une interface SD-WAN Edge, le dispositif Edge peut les traiter par erreur en tant que fragments IPv4 et provoquer une fuite d'enregistrement de fragments. Au fil du temps, cela peut arrêter le traitement de tous les fragments et provoquer l'abandon de tous ces paquets. Pour un client utilisant l'authentification RADIUS, l'authentification peut être interrompue pour tous les dispositifs Edge en même temps.

  Dans une entreprise n'utilisant pas de build fixe, la seule solution consiste à redémarrer tous les dispositifs Edge.

• Problème résolu 117775 : Une destination non-SD-WAN via une passerelle (NSD) peut entrer par intermittence dans un état dans lequel les tunnels IPsec font constamment l'objet d'un bagotement (c'est-à-dire qu'ils sont désinstallés et recréés).

  Le client observe que les tunnels sont actifs pendant plusieurs secondes, inactifs pendant plusieurs secondes, puis actifs à nouveau. Ce cycle recommence et s'arrête de lui-même. Comme il s'agit d'un problème de synchronisation, le cycle peut se répéter sur plusieurs jours et potentiellement à l'infini. Le problème se produit en raison d'une condition de concurrence lorsqu'un tunnel NSD avec un grand nombre de connexions IKE de phase 2 est en cours d'activation et que la passerelle tente de transférer le trafic sur l'une de ces connexions IKE de phase 2 avant qu'elle ne soit entièrement active, ce qui entraîne la désinstallation et la recréation de l'ensemble du tunnel avant que le cycle ne recommence.

  Sur un site n'utilisant pas de passerelles avec un correctif pour ce problème, les possibilités de solutions sont limitées dans la mesure où il s'agit d'un problème de synchronisation. Une solution potentielle consiste à configurer les tunnels NSD par petits lots afin qu'ils soient négociés plus rapidement et ainsi éviter la fenêtre dans laquelle le trafic arrive avant que le tunnel soit prêt.

• Problème résolu 121368 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données, déclencher un noyau et redémarrer en conséquence.

  Ce problème est déclenché par les utilisateurs d'accès distant qui accèdent à Internet/au cloud via la passerelle. Si le point de terminaison Internet/cloud répond avec un paquet volumineux qui nécessite une fragmentation, le service de passerelle échoue lors de la tentative de fragmentation du paquet.

Résolu dans Edge/Gateway version R5201-20230619-GA

La build R5201-20230619-GA d'Edge a été publiée le 22/06/2023 et constitue la 1re build cumulative d'Edge pour la version 5.2.0.

Cette build cumulative d'Edge/de Gateway résout les problèmes critiques ci-dessous depuis la build GA R5200-20230530-GA initiale.

Important:

Il est fortement recommandé aux utilisateurs de la build 5.2.0.0 d'Edge ou de Gateway de mettre à niveau leurs dispositifs Edge et/ou passerelles vers la version 5.2.0.1.

• Problème résolu 115150 : Lorsqu'un client déploie une destination non-SD-WAN (NSD) ou un service de sécurité cloud (CSS) avec un type Zscaler et que le contrôle de santé L7 est activé, le client peut observer qu'un ou plusieurs tunnels sont inactifs en raison d'un échec du contrôle de santé L7.

  Ce problème peut se produire sur un tunnel principal ou un tunnel secondaire. Lorsqu'une passerelle VMware SD-WAN Gateway gère plusieurs contrôles de santé L7, une fuite NAT causée par les sondes de contrôle de santé L7 entraîne l'échec du tunnel NSD/CSS qui ne peut pas être récupéré sans redémarrer la passerelle.

• Problème résolu 117638 : Lorsque l'utilisateur accède à Surveiller (Monitor) > Dispositif Edge (Edge) > Liens (Links) et active le mode direct pour un dispositif VMware SD-WAN Edge utilisant la version 5.2.0, SASE Orchestrator ne fournit pas de statistiques en temps réel.

  En outre, l'utilisateur observe une indication Attente du dispositif Edge... (Waiting for Edge...) qui finit par expirer. Ce problème se produit sur le dispositif Edge en raison de la façon dont une build d'Edge version 5.2.0 gère les statistiques de liens LTE/USB lors de leur chargement sur Orchestrator.

Résolu dans la version R5200-20230530-GA d'Edge/de Gateway

La build R5200-20230530-GA d'Edge et de Gateway a été publiée le 31/05/2023 et résout les problèmes suivants depuis la build R5102-20230310-GA d'Edge et de Gateway.

Note:

La version 5.2.0 contient tous les correctifs d'Edge et de Gateway répertoriés dans les Notes de mise à jour de la version 5.0.0 et de la version 5.0.1, ainsi que tous les correctifs d'Edge et de Gateway dans les Notes de mise à jour de la version 5.1.0 jusqu'à la build susmentionnée.

• Problème résolu 48032 : Il n'existe aucun moyen de suivre les statistiques de lecture et d'écriture du disque du dispositif VMware SD-WAN Edge pour l'analyse en cas de panne de disque.

  Une méthode actuelle permet de suivre la quantité d'écriture sur un disque dans /velocloud/log, mais les données ne sont pas précises, car elles ne font que suivre l'ensemble des données écrites et non le nombre d'écritures. Ce ticket ajoute « Statistiques du disque » (Disk Stats) sous le diagnostic à distance « Informations système » (System Information) afin que l'équipe d'ingénierie VMware puisse se reporter à ces statistiques en cas d'autorisation de retour de marchandise (RMA, Return Merchandise Authorization) du dispositif Edge basée sur le disque.

• Problème résolu 54573 : Lors de l'exécution d'un vidage de la table de routage, la sortie peut afficher une valeur de mesure incorrecte pour certaines routes connectées.

  Ce problème est dû au fait que le service Edge ne reçoit pas la notification appropriée d'ajout de route d'interface à partir du noyau Edge.

• Problème résolu 57170 : une entreprise cliente utilisant BGP, des liens privés et une passerelle partenaire peut subir une perte de connectivité avec les clients derrière la passerelle partenaire vers le serveur derrière un dispositif VMware SD-WAN Edge.

  Le trafic Internet utilise le réseau MPLS plutôt que le processus de transfert NAT.

• Problème résolu 58244 : Un client utilisant BGP et une passerelle partenaire peut observer des problèmes de connectivité pour le trafic utilisant la PG.

  Le problème provient de la non-installation de la route PSBR et cela peut s'observer lors de l'examen du vidage de la table de routage. Cela est dû au fait que la passerelle a été supprimée et rajoutée. Les événements de routes ont été abandonnés avec l'erreur « file d'attente de routes introuvable pour le segment 1 » (route queue not found for segment 1).

• Problème résolu 68748 : Lorsqu'un périphérique client utilisant le système d'exploitation Windows est connecté à un dispositif VMware SD-WAN Edge, le rapport d'événements pour « Nouveau périphérique client détecté » (New Client Device Seen) est la version incorrecte du système d'exploitation.

  Le dispositif Edge tronque la description dans le fichier dhcp_fingerprints.json, ce qui empêche le client de disposer du système d'exploitation approprié pour ce périphérique client connecté.

• Problème résolu 82808 : Pour un dispositif VMware SD-WAN Edge qui utilise un service de sécurité cloud (CSS) et sur lequel le contrôle de santé L7 est activé, le client peut observer l'échec du trafic lors de l'utilisation de ces tunnels CSS, même si VMware SASE Orchestrator continue de marquer les tunnels comme étant actifs (UP).

  Même si la sonde L7 tombe en panne avec une erreur HTTP 4XX, la passerelle VMware SD-WAN Gateway ne reconnaît pas la panne et n'indique pas à Orchestrator de marquer les tunnels CSS comme étant inactifs (DOWN).

• Problème résolu 84235 : Un dispositif VMware SD-WAN Edge peut subir une panne du service de plan de données et redémarrer pour reprendre.

  Si le dispositif Edge libère des paquets IKEv2 fragmentés (en mode PKI activé) en même temps qu'un bagotement de tunnel, il est peu probable qu'un état « à double libération » se produise et déclenche une exception sur le service du dispositif Edge, ce qui entraîne un échec et le redémarrage.

• Problème résolu 86994 : Sur une entreprise cliente sur laquelle le système dynamique site distant vers site distant est activé, lors de la tentative de dépannage d'un dispositif VMware SD-WAN Edge dans cette entreprise, la commande dispcnt de débogage ne fonctionne pas.

  La commande de débogage dispcnt ne fournit pas toutes les valeurs de compteur et échoue avec l'erreur Domain (null) does not exist. Un échec se produit également lorsque vous faites référence aux journaux pertinents d'un bundle de diagnostics Edge. Cela gêne considérablement le dépannage d'un problème de réseau client.

  Ce problème se produit dans les entreprises dans lesquelles un système dynamique site distant vers site distant est activé en raison de la grande quantité de tunnels créés et désinstallés sur chaque peer. Les compteurs utilisés pour stocker diverses mesures des peers sont stockés dans une mémoire partagée et, au fil du temps, ces segments de mémoire partagée passent à un état incorrect en raison d'une collision, et les compteurs ne sont pas extraits par la commande dispcnt.

  Sans correctif pour ce problème, l'utilisateur peut uniquement effacer l'état en effectuant un redémarrage du service du dispositif Edge affecté.

• Problème résolu 89332 : Si le répertoire /velocloud du dispositif VMware SD-WAN Edge est plein ou n'est pas disponible en écriture, le client ignore cet état dans Événements (Events).

  Le client peut alors uniquement constater que le dispositif Edge ne publie pas d'événements supplémentaires avant plusieurs jours. L'écriture d'un fichier dans le répertoire /velocloud permet le signalement d'événements à Orchestrator. Si le répertoire est plein ou qu'il existe un problème avec le disque de sorte qu'il passe en mode lecture seule, le client et l'équipe d'ingénierie ou le support VMware ne peut en aucune façon le savoir, car il n'existe aucun événement ou aucune journalisation pour l'en avertir.

  Le correctif de ce problème ajoute une nouvelle entrée de journal écrite dans un dossier différent pour indiquer clairement ce qui se passe avec une sortie semblable à la suivante :

  • edge:b1-edge1:~# cat /var/log/log_eventgen.log

  • 2023-05-19 13:03:46,628 Unable to create event save file: [Errno 30] Read-only file system: '/velocloud/events/client/event.1684501426626.mgp7kfvg'

  • 2023-05-19 13:03:46,634 events.EventPackage failure, queing to MGD

• Problème résolu 90044 : Lorsqu'une passerelle VMware SD-WAN Gateway est configurée avec une sonde ICMP et que la passerelle est redémarrée, la sonde ICMP ne récupère pas et reste inactive.

  L'état de la sonde ICMP dans debug.py --icmp indique INACTIF (DOWN) après un redémarrage de la passerelle.

  Sur une passerelle sans correctif pour ce problème, la solution consiste à désactiver la sonde ICMP, puis à la réactiver.

• Problème résolu 92142 : Lorsqu'un périphérique derrière un dispositif VMware SD-WAN Edge tente de communiquer avec un périphérique directement connecté au dispositif Edge via une interface routée avec un VLAN ou une sous-interface configuré(e), la communication peut échouer.

  Lorsque l'option NAT Direct est configurée sur une interface routée, tout le trafic envoyé directement via cette interface (sur la sous-couche) doit utiliser la NAT à l'aide de l'adresse IP de l'interface routée. Toutefois, la NAT n'est pas appliquée au trafic vers les autres adresses IP et à partir de celles-ci dans le même sous-réseau que l'interface routée lorsque celle-ci est une sous-interface ou utilise un VLAN. Cette anomalie ne se rencontre pas si la destination se trouve à un ou plusieurs tronçons, car le dispositif Edge n'applique pas NAT Direct et le trafic fonctionne (voir la remarque ci-dessous pour connaître les répercussions lorsqu'un dispositif Edge utilise une version définitive).

  Note:

  Il est possible qu'une ancienne version de SASE Orchestrator ait configuré par inadvertance NAT Direct sur une interface principale avec un VLAN ou une sous-interface configuré(e). Si cette interface envoie le trafic direct à une destination qui se trouve à un ou plusieurs tronçons, le client ne constate jamais de problème, car le paramètre NAT Direct n'a pas été appliqué. Toutefois, lorsqu'un dispositif Edge est mis à niveau vers la version 5.2.0 et les versions ultérieures avec un correctif pour ce problème, il en résulte une modification du comportement de routage, car ce cas d'utilisation spécifique n'a pas été mis en œuvre dans les versions antérieures.

  En d'autres termes, étant donné qu'un dispositif Edge de version 5.2.0 met désormais en œuvre NAT Direct comme prévu pour tous les cas d'utilisation, le trafic qui fonctionnait auparavant (car NAT Direct n'était pas appliqué en raison de l'anomalie) peut désormais tomber en panne, car le client n'a jamais constaté que l'interface de NAT Direct était vérifiée avec un VLAN ou une sous-interface configuré(e).

  Par conséquent, un client mettant à niveau son dispositif Edge vers la version 5.2.0 ou une version ultérieure doit d'abord vérifier ses paramètres de profils et d'interface Edge pour s'assurer que l'option NAT Direct est configurée uniquement en cas de besoin explicite et pour désactiver ce paramètre s'il n'est pas nécessaire, en particulier si un VLAN ou une sous-interface est configuré(e) pour cette interface.

• Problème résolu 92927 : Lorsqu'une interface de dispositif VMware SD-WAN Edge est désactivée, elle continue d'avoir un lien avec un périphérique connecté.

  Lorsqu'une interface est sélectionnée pour être désactivée via Orchestrator, elle est supprimée du contrôle DPDK du dispositif Edge et placée sous le contrôle du pilote de noyau du dispositif Edge. Cependant, le script qui effectue cette conversion configure l'administration du noyau sur l'interface. Par conséquent, si l'interface est connectée, il tente de négocier automatiquement avec le périphérique connecté.

• Problème résolu 92400 : Sur un site client configuré avec une topologie à haute disponibilité et sur lequel les interfaces Edge sont configurées avec des sous-interfaces, la convergence du dispositif Edge passif prend plus de temps après un basculement HA.

  Les valeurs ARP gratuit (Gratuitous ARP) et ARP next-hop (Nexthop ARP) ne sont pas envoyées à partir de la sous-interface, ce qui entraîne un temps de convergence supérieur aux sous-secondes attendues. 

• Problème résolu 93141 : Sur un site déployé avec une topologie à haute disponibilité, un client utilisant un commutateur L2 en amont de la paire de dispositifs Edge HA peut observer dans les journaux de commutateur la preuve d'une boucle de trafic L2, bien qu'il n'y ait pas de boucle réelle.

  Ce problème est le résultat de l'envoi par le dispositif Edge HA du signal de pulsation de l'interface HA avec l'adresse MAC virtuelle à Orchestrator au lieu de l'adresse MAC réelle de l'interface, ce qui est dû au fait que le dispositif Edge HA stocke l'adresse MAC virtuelle dans son fichier MAC. Par conséquent, le commutateur L2 connecté détecte le trafic à partir de la même adresse MAC source provenant de deux interfaces Edge différentes et le consigne en tant que boucle L2. Ce problème est superficiel au niveau du journal, car il n'y a pas de boucle L2 réelle et il n'y a pas d'interruption du trafic client ou de perte de contact avec Orchestrator résultant de ce problème. Par conséquent, il n'y a aucune incidence sur le client et ce dernier peut ignorer les événements de détection de boucle L2 des commutateurs montants qui proviennent de l'interface HA du dispositif Edge (généralement GE1).

• Problème résolu 93965 : Un dispositif VMware SD-WAN Edge peut subir une panne du service de plan de données, déclencher un cœur et redémarrer pour reprendre.

  La vérification d'un cœur confirme que le service Edge s'est arrêté avec un signal SIGXCPU. Le système d'exploitation Edge dispose d'un socket Unix utilisé comme file d'attente pour la communication d'événements d'interface entre les threads. Ce problème est dû au fait que la profondeur de socket est trop petite, ce qui entraîne le blocage des threads et le déclenchement du signal SIGXCPU.

• Problème résolu 95399 : Lorsque l'interface routée d'un dispositif VMware SD-WAN Edge est physiquement branchée ou débranchée, l'utilisateur n'observe pas d'événement Interface du dispositif Edge active ( Edge Interface Up) ou Interface du dispositif inactive (Edge Interface Down) sur VMware SASE Orchestrator.

  Le problème est lié à la valeur dhclient d'abord ajoutée à la version 4.5.1 d'Edge et désormais incluse dans chaque build (5.0.x, 5.1.x). La valeur Dhclient n'a pas été configurée pour envoyer des événements d'activation et de désactivation de l'interface à Orchestrator.

• Problème résolu 95565 : Sur un site utilisant une topologie à haute disponibilité, le dispositif VMware SD-WAN Edge actif risque de subir une panne du service de plan de données avec un noyau généré et déclencher un basculement à haute disponibilité.

  Ce problème est déclenché par le bagotement d'un ou de plusieurs liens WAN du dispositif Edge actif (panne, puis activation rapide) tout en utilisant SNMP lorsque des requêtes SNMP sont fréquentes. Il existe un problème de synchronisation par lequel l'interface se réactive et la requête SNMP peut déclencher un blocage. Cela entraîne l'échec du service de plan de données et la génération d'un noyau. Bien qu'un seul bagotement de lien WAN puisse provoquer ce problème, plus la fréquence des bagotements du lien WAN est élevée, plus ce problème risque de se produire.

  Sur une paire de dispositifs Edge HA qui rencontre ce problème et qui ne dispose d'aucun correctif, la solution consiste à désactiver SNMP, car il s'agit d'un problème de synchronisation, ce qui réduit le risque.

• Problème résolu 95950 : lorsqu'un utilisateur configure les paramètres de l'interface d'un dispositif VMware SD-WAN Edge avec 128 segments, le dispositif Edge peut subir une panne du service de plan de données, générer un vidage de mémoire et redémarrer.

  Lorsque le dispositif Edge est configuré avec 128 segments, l'application de la règle iptable prend trop de temps, ce qui entraîne une exception du moniteur mutex et l'échec du service Edge.

• Problème résolu 95850 : Sur une entreprise cliente dans laquelle OSPF est utilisé, lorsqu'un utilisateur génère un bundle de diagnostics pour un dispositif VMware SD-WAN Edge, il se peut que les routes OSPF deviennent instables lors de la génération du bundle, ce qui entraîne une interruption du trafic client.

  Dans le cadre de la génération du bundle de diagnostics, les commandes vcdbgdump -r remote-routes et vcdbgdump -r remote_routes sont exécutées. Étant donné que ces commandes prennent plus de 40 secondes dans un environnement client, les messages Hello d'OSPF qui sont mis en file d'attente sur le thread du répartiteur d'événements ne sont pas traités. De ce fait, le voisinage OSPF devient instable, ce qui entraîne une panne du réseau.

  Sur un dispositif Edge sans correctif pour ce problème, un client ne doit pas générer de bundle de diagnostics, sauf dans une fenêtre de maintenance, ou contacter le support VMware SD-WAN pour générer le bundle, car le personnel dispose d'outils internes pour éviter que le problème ne se produise de manière temporaire.

• Problème résolu 96710 : Lorsqu'un site client est configuré avec une topologie à haute disponibilité et que la détection de perte de signal (LOS) est activée pour les interfaces du dispositif Edge HA, lorsque la connectivité est perdue sur les interfaces du dispositif Edge actif et rétrogradée en Passif (Standby), et que la connectivité de l'interface est restaurée ultérieurement, le dispositif Edge passif ne détecte pas la connectivité restaurée.

  Lorsqu'un dispositif Edge devient passif en raison de la détection de la LOS sur une interface lorsqu'elle était active, même si la connectivité est restaurée après un certain temps lorsque le dispositif Edge est dans l'état passif, SD-WAN ne peut pas détecter la connectivité restaurée, car la surveillance de la LOS ne peut pas s'effectuer sur le dispositif Edge passif. L'interface est toujours considérée comme inactive en fonction du dernier état connu de la LOS.

  Sur un dispositif Edge HA sans ce correctif, un basculement HA forcé mène le dispositif Edge passif (désormais actif) à utiliser ARP pour examiner la connectivité restaurée de ses interfaces.

• Problème résolu 97953 : Un utilisateur opérateur ou partenaire n'a pas la possibilité d'effacer le cache ARP sur une passerelle VMware SD-WAN Gateway.

  Sur Gateway utilisant la version 5.2.0 ou une version ultérieure, un utilisateur a la possibilité d'utiliser la commande debug.py --clear_arp_cache pour effacer son cache ARP.

• Problème résolu 98223 : lorsque l'analyse Edge Network Intelligence est activée sur un dispositif VMware SD-WAN Edge, celui-ci peut perdre le contact avec l'instance de VMware SASE Orchestrator et Orchestrator marque le dispositif Edge comme inactif dans son interface utilisateur.

  Lorsque l'analyse est activée, la communication du dispositif Edge avec le serveur principal d'analyse est parfois mélangée avec la communication du dispositif Edge avec Orchestrator. Cela entraîne une perte de communication avec Orchestrator qui déclare que le dispositif Edge est inactif alors qu'il ne l'est pas.

• Problème résolu 98359 : Si un client active la détection de perte de signal (LoS) pour une interface Edge qui utilise également une sous-interface, la LOS ne détecte pas les pannes de connectivité sur la sous-interface.

  Dans les versions antérieures, la détection LoS n'est pas prise en charge pour les sous-interfaces et, en raison de cette perte de connectivité sur les sous-interfaces, n'est pas détectée.

• Problème résolu 98634 : Lorsqu'il examine Dispositif Edge (Edge) > Surveiller (Monitor) > Transport pour un dispositif Edge avec plusieurs liens, un utilisateur peut observer une différence dans les mesures entre les deux liens.

  Ce problème provient de la duplication de l'ID logique d'un lien WAN sur plusieurs dispositifs Edge, qui entraîne des statistiques inexactes pour ce lien.

• Problème résolu 98694 : lorsqu'une entreprise cliente est configurée avec des routes statiques redondantes, si la route principale tombe en panne, les autres routes ne sont pas annoncées et le trafic est abandonné.

  Lorsque l'interface tombe en panne sur un dispositif VMware SD-WAN Edge, les autres routes ne sont pas annoncées à la passerelle VMware SD-WAN Gateway, même si les routes via l'interface sont désormais inaccessibles. Les routes du préfixe ne sont pas présentes dans la passerelle, même s'il existe d'autres routes via d'autres interfaces pour ces préfixes sur le dispositif Edge. Ce problème est dû au fait que le service SD-WAN envoie une suppression de route sans vérifier s'il existe une autre route statique accessible lors du traitement d'une interface inactive.

• Problème résolu 99193 : Pour un dispositif VMware SD-WAN Edge qui est configuré comme un dispositif Spoke Edge et qui utilise activement IPv6, si ce dispositif Edge exécute la version 5.x et est rétrogradé vers la version 4.5.x ou une version antérieure, le trafic IPv6 destiné au dispositif Spoke Edge est abandonné et, s'il existe d'autres routes IPv6, le trafic ne les prend pas, mais continue à se diriger vers le dispositif Spoke Edge rétrogradé sur lequel elles sont abandonnées, entraînant ainsi une perte de paquets.

  Lorsqu'un dispositif Spoke Edge est rétrogradé de la version 5.x vers la version 4.5.x ou une version antérieure et tombe en panne, le dispositif Hub Edge supprime les routes IPv6 avec le next-hop comme ce dispositif Spoke Edge de la base d'informations de transfert (FIB), mais les conserve dans la base d'informations de routage (RIB). Plus tard, lorsque le dispositif Spoke Edge rétrogradé démarre, le Hub restaure les routes IPv6 dans la FIB, ce qui entraîne le déplacement du trafic de ces préfixes vers le dispositif Spoke Edge et son abandon à cet emplacement. Ce problème persiste jusqu'à ce qu'un temporisateur d'actualisation périmé démarre et vide les routes v6 au bout de 5 minutes.

• Problème résolu 99215 : Sur les modèles VMware SD-WAN Edge 610, 620, 640 et 680, l'interface SFP2 peut cesser de recevoir des paquets lorsque l'utilisateur désactive l'interface SFP1 ou la configure comme commutée.

  Sur ces modèles d'Edge, l'interface SFP2 peut cesser de recevoir des paquets si SFP1 est configurée comme routée et que l'utilisateur choisit de désactiver SFP1 ou de reconfigurer SFP1 comme commutée.

• Problème résolu 100010 : Pour un dispositif VMware SD-WAN Edge déployé avec des liens WAN privés configurés pour IPv4 et IPv6, lorsqu'un utilisateur génère un bundle de diagnostics ou exécute le diagnostic à distance « Chemins de liste » (List Paths), le dispositif Edge peut rencontrer une fuite de mémoire.

  Lorsque le trafic est exécuté via des liens privés, SD-WAN vérifie d'abord si l'adresse IPv4 est configurée et, si c'est le cas, la valeur est enregistrée dans JSON, puis SD-WAN vérifie à nouveau si l'adresse IPv6 est configurée. Si une adresse IPv6 est présente, SD-WAN remplace la valeur précédemment stockée avant de l'ajouter au tableau JSON, ce qui entraîne une fuite de mémoire. Plus l'échelle du trafic traité par le dispositif Edge est grande, plus la fuite de mémoire est importante lorsque les actions de déclenchement s'effectuent.

• Problème résolu 100172 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données, générer un cœur et redémarrer pour reprendre.

  L'utilisateur peut rencontrer ce problème s'il accède à un dispositif Edge via la passerelle en utilisant SSH et que cette session SSH génère un message d'erreur FRAG_NEEDED ICMP. Étant donné que la passerelle a reçu le paquet via l'interface gwd1 locale, pkt_in->skb->vc_sk->raw est NULL et déclenche la panne de service et le cœur.

• Problème résolu 100237 : Pour une entreprise cliente dans laquelle une passerelle partenaire est utilisée et la PG annonce une route sécurisée par défaut à une passerelle VMware SD-WAN Gateway, un utilisateur client peut rencontrer un échec du téléchargement d'un fichier directement à partir d'Internet.

  Le scénario complet inclut le dispositif Edge qui utilise plusieurs liens WAN avec l'option « Remplacement de route par défaut sécurisé » (Secure Default Route Override) configurée et une Business Policy créée dans laquelle le paramètre Service réseau (Network Service) est défini sur Direct. Dans ce scénario, le flux du trafic utilisant cette Business Policy peut choisir successivement une adresse IP WAN différente à chaque fois et le téléchargement échoue.

  Sans correctif pour ce problème, l'utilisateur doit configurer la Business Policy pour limiter tout le trafic à un lien WAN en le marquant comme Obligatoire (Mandatory).

• Problème résolu 100359 : Lorsqu'un filtre sortant OSPFv2 est configuré pour abandonner une route récapitulative, le dispositif Edge continue d'annoncer ces routes.

  Les routes OSPFv2 sont annoncées, même après la configuration de l'option « Ignorer » (Ignore) sous « Annonce de route » (Route Advertisement) pour OSPF sous une interface particulière.

• Problème résolu 101102 : Lorsqu'une instance de VMware SD-WAN Edge initialement attribuée à une passerelle hébergée est réattribuée à une passerelle partenaire, la connexion au dispositif Edge via la passerelle cesse de fonctionner en utilisant SSH.

  Lorsqu'il est réattribué à une passerelle partenaire, le dispositif Edge perd l'adresse IP vce1 et, par conséquent, la connexion via la passerelle ne fonctionne pas en utilisant SSH.

  Sur un dispositif Edge sans correctif pour ce problème, un redémarrage du service Edge initié par l'utilisateur corrige le problème.

• Problème résolu 101144 : Une passerelle VMware SD-WAN Gateway peut subir des fuites de paquets si ces derniers sont dans le désordre.

  Ces fuites peuvent s'observer lors de l'exécution de vcdbgdump -r dpdk-leak-dump et elles se trouvent dans pkt_path_alloc et pkt_path_ooo. Les paquets sont bloqués dans la file d'attente d'anneaux reseq VCMP et ne sont pas traités.

• Problème résolu 101753 : un dispositif VMware SD-WAN Edge peut apparaître hors ligne sur l'instance de VMware SASE Orchestrator, même s'il est actif et transmet le trafic.

  Ce problème se produit, car le dispositif Edge continue à acheminer le trafic vers Orchestrator à partir d'une adresse IP qui n'est plus disponible, ce qui entraîne l'abandon du trafic de retour.

• Problème résolu 102607 : Un dispositif VMware SD-WAN Edge peut subir une panne du service de plan de données s'il utilise une destination non-SD-WAN via une passerelle ou si BGP sur NSD est également configuré.

  Un problème peut se produire lorsqu'une route de centre de données NSD et une route entre deux dispositifs Edge utilisent le même préfixe. Dans ce scénario, les paquets destinés et chiffrés pour le DC peuvent atteindre les tunnels de gestion SD-WAN, ce qui peut entraîner une fuite de mémoire, voire une panne de service.

• Problème résolu 102655 : Pour une entreprise cliente dans laquelle BGP est utilisé pour le routage, BGP sur un segment non global ne s'active pas sur une sous-interface de dispositif Edge.

  Un problème se produit si l'interface principale du dispositif Edge sur le segment global et une sous-interface sur un segment non global disposent de la même adresse IP et qu'un overlay WAN est également configuré sur l'interface principale. Le problème de non-activation de BGP se produit probablement après un redémarrage du dispositif Edge ou du service.

  Sur un dispositif Edge sans correctif pour ce problème, supprimez l'adresse IP de sous-interface et la configuration associée à BGP, puis procédez à la reconfiguration avec une adresse IP unique.

• Problème résolu 102693 : sur un site configuré avec une topologie à haute disponibilité, lorsqu'un utilisateur essaie de déterminer la version logicielle et la build d'usine que les dispositifs VMware SD-WAN Edge HA utilisent, ces champs peuvent être vides dans VMware SASE Orchestrator.

  Lorsque HA est activé pour une paire de dispositifs Edge, les dispositifs Edge peuvent ne pas envoyer les versions logicielles et de build d'usine à Orchestrator lors du signal de pulsation initial. Par conséquent, Orchestrator ne peut pas les afficher.

• Problème résolu 103558 : Sur une entreprise cliente utilisant Edge Network Intelligence, le tableau de bord ENI peut afficher « Aucune adresse IP de gestion attribuée » (No Management IP Assigned) pour ce dispositif Edge lorsque l'analyse est activée pour un dispositif VMware SD-WAN Edge.

  Lorsque l'analyse est activée, dans de rares cas, le dispositif Edge n'envoie pas d'adresse IP de gestion au serveur principal Edge Network Intelligence.

• Problème résolu 103700 : Les applications dans une carte d'application configurée avec mustNotPerformDpi (l'inspection approfondie des paquets (DPI) ne doit pas s'effectuer) peuvent toujours obtenir leur classification via la DPI lorsque le client dispose d'un déploiement à grande échelle.

  Les utilisateurs clients ne peuvent pas accéder au site Web ou à l'application si cette dernière est incorrectement classée.

  Dans une entreprise cliente à grande échelle comptant environ 8 000 entrées dans le cache de la base de données rapide de classification des applications, des conflits peuvent se produire lors de la recherche d'une application. En cas de conflit, bien qu'une application soit configurée avec mustNotperformDpi, elle sera toujours classée via la DPI.

  Sur une entreprise sans correctif pour ce problème, la solution consiste à configurer une Business Policy dans laquelle les sous-réseaux de l'application ou du domaine sont utilisés pour diriger le trafic via le backhaul direct ou Internet.

• Problème résolu 103708 : Lorsque de nouvelles règles sont ajoutées dans une configuration de filtre BGP, des routes BGP inattendues peuvent être reçues et envoyées par le dispositif VMware SD-WAN Edge.

  Lorsque de nouvelles règles sont ajoutées aux filtres BGP à partir d'Orchestrator, les listes de préfixes sont ajoutées dans la configuration de routage du dispositif Edge sans supprimer les anciennes entrées. Ce comportement entraîne des listes de préfixes de routes périmées et un comportement de filtrage inattendu.

• Problème résolu 103962 : Les routes connectées IPv6 et IPv4 redistribuées dans OSPFv3 ou BGPv6 présentent des mesures différentes, ce qui peut entraîner un routage différent pour le trafic IPv6 par rapport à IPv4.

  Actuellement, les routes connectées IPv6 correspondant à une interface routée sont installées avec une mesure différente de celle des routes connectées IPv4 sur la même interface. Cela est dû aux différentes mesures fournies par le noyau du système d'exploitation Edge pour les routes IPv4 et IPv6. Lorsqu'elles sont redistribuées dans des protocoles dynamiques tels qu'OSPF/BGP, cette différence est propagée dans les mesures IPv4/IPv6.

• Problème résolu 104046 : Pour un site client déployé avec une topologie à haute disponibilité, VMware SASE Orchestrator peut afficher le dispositif Edge passif comme étant actif alors qu'il est en réalité inactif.

  La déconnexion du câble d'interface HA entre les dispositifs Edge HA ou la mise hors tension du dispositif Edge passif constituent les scénarios dans lesquels cela se produit. Ce problème est dû au fait que le dispositif Edge HA actif envoie un état Actif (Active) lorsque le dispositif Edge passif est inactif en raison d'une vérification par le processus de gestion du dispositif Edge actif qui fait uniquement référence à la configuration de HA, tout en ignorant l'état réel du dispositif Edge passif.

• Problème résolu 104513 : pour une entreprise connectée via BGP à une passerelle partenaire qui déploie des sondes ICMP, si une sonde ICMP devient inactive, les utilisateurs clients peuvent observer l'abandon et la non-récupération du trafic.

  Lorsqu'une sonde ICMP devient inactive, l'état d'accessibilité des routes BGP de la passerelle partenaire devient Faux et tout le trafic utilisant ces routes échoue. Ce problème est dû au fait que la passerelle vérifie l'état de la sonde ICMP sur toutes les routes de transfert de la passerelle partenaire, y compris les routes BGP. Si l'état d'une sonde ICMP est inactif, la passerelle partenaire marque également les routes BGP comme étant inactives.

  Sur une passerelle sans correctif pour ce problème, la seule solution consiste à désactiver les sondes ICMP. Toutefois, cette opération pouvant perturber d'autres clients qui utilisent la même passerelle partenaire, elle doit toujours être accompagnée de cette mise en garde.

• Problème résolu 105433 : pour un site utilisant une topologie à haute disponibilité améliorée, les dispositifs VMware SD-WAN Edge HA peuvent être mis hors ligne avec VMware SASE Orchestrator si une interface WAN sur le dispositif Edge passif fait l'objet d'un bagottement.

  Le dispositif Edge passif ne synchronise pas la mise à jour de l'adresse IP dynamique sur le dispositif Edge actif lorsque l'état de l'interface est modifié. En outre, à cause de la connectivité entre le site du dispositif Edge HA et Orchestrator, le dispositif Edge échoue. Cela affecte uniquement le trafic de gestion et n'affecte pas le trafic client.

• Problème résolu 105440 : lorsque le type de données pour l'option 43 DHCP est défini sur « Texte » (Text) et que la « Valeur » (Value) est configurée sous la forme d'une chaîne de texte qui commence par un chiffre, l'option est ignorée et une erreur est signalée.

  Par exemple, la valeur de l'option 43 est configurée en tant qu'adresse IP. L'utilisateur voit un événement avec un message "messages" : "dhcp.py:527: Invalid value for option 43: <text string configured>, ignored".

• Problème résolu 105492 : Les paquets L2 basés sur IPv6 non destinés à une adresse MAC L2 du dispositif VMware SD-WAN Edge sont traités inutilement au lieu d'être abandonnés.

  Il est prévu que les paquets IPv6 transmis en monodiffusion vers une adresse MAC de destination qui ne correspond pas à l'interface MAC de l'interface du dispositif Edge soient abandonnés.

• Problème résolu 105686 : La mise à niveau d'une passerelle VMware SD-WAN Gateway sur 82599 SR-IOV vers Gateway build 5.0.1.2 n'active pas les interfaces de carte réseau SR-IOV.

  Le pilote ixgbevf n'était pas disponible sur la build de Gateway exécutant le noyau 4.15.0-201-generic. Les cumuls de sécurité du noyau Ubuntu (à partir de la version 4.15.0.159) présentent un rétroportage à partir du noyau principal et skb_frag_off est désormais disponible dans l'en-tête du noyau, de sorte que la propre définition de skb_frag_off du pilote ixgbevf n'est pas nécessaire.

  Les opérateurs ne doivent pas mettre à niveau Gateway version 5.0.1.2 si des interfaces 82599 SRIOV sont utilisées.

• Problème résolu 105933 : un utilisateur ne peut pas établir de connexion SSH aux modèles de dispositifs VMware SD-WAN Edge 610/610-LTE ou 520/540 via une interface routée.

  Il n'existe aucune règle d'abandon pour les paquets SSH en double provenant d'un pilote af-pkt utilisé par le système d'exploitation du dispositif Edge affecté. De ce fait, le noyau Edge reçoit 2 paquets SSH : un via l'interface vce1 et un autre paquet SSH direct en raison de la nature du pilote. Le noyau Edge est alors amené à répondre à 2 demandes SSH, ce qui provoque la confusion du client SSH et l'échec de la connexion SSH.

  Pour un dispositif Edge sans correctif pour ce problème, l'utilisateur peut ajouter une règle de table IP pour abandonner les paquets SSH reçus d'interfaces autres que vce1.

• Problème résolu 106017 : Lors du déploiement d'un fichier OVA de passerelle VMware SD-WAN Gateway sur vSphere, les clients peuvent rencontrer un avertissement selon lequel VMware Tools n'est pas installé sur la VM alors qu'en réalité il l'est.

  Le message complet est le suivant : « Tools n'est pas installé dans GuestOS. Installez la dernière version d'open-vm-tools ou de VMware Tools pour activer GuestCustomization. » (Tools is not installed in the GuestOS. Please install the latest version of open-vm-tools or VMware Tools to enable GuestCustomization) Le message est trompeur, car les outils sont en fait installés sur l'image de la passerelle, mais l'attribut version est manquant, ce qui déclenche l'erreur. Ce message d'erreur trompeur n'a aucune incidence sur la fonctionnalité de configuration.

• Problème résolu 106123 : VMware SD-WAN peut mal classer les paquets, car le moteur d'inspection approfondie des paquets (DPI, Deep Packet Inspection) n'est pas à la dernière build.

  Lorsqu'un dispositif Edge ou une passerelle classe un paquet de manière incorrecte, cela peut entraîner de nombreux problèmes pour les clients SD-WAN. Le correctif met à niveau le moteur DPI du dispositif Edge et de la passerelle vers la build la plus actuelle, ce qui garantit que le service SD-WAN classe le trafic client à un niveau de précision supérieur.

• Problème résolu 106225 : Les routes connectées et statiques associées à une sous-interface sont purgées des dispositifs VMware SD-WAN Edge distants lorsque le lien WAN tombe en panne.

  Lors de l'annonce de routes connectées pour les sous-interfaces, SD-WAN utilise l'ID de sous-interface à la place d'un index de tableau. La vérification d'un indicateur d'annonce s'effectue alors sur l'interface inappropriée. Par conséquent, des événements d'ajout/de suppression lors des bagotements de l'interface sont manquants pour les nœuds distants.

  Sur un dispositif Edge sans correctif pour ce problème, le client doit configurer Annoncer (Advertise) sur toutes les interfaces pour éviter ce problème.

• Problème résolu 106331 : pour une entreprise connectée via BGP à une passerelle partenaire qui déploie des sondes ICMP, si une sonde ICMP devient inactive sur la passerelle partenaire, les utilisateurs clients peuvent observer l'abandon et la non-récupération du trafic.

  Ce problème est dû au fait que le dispositif VMware SD-WAN Edge vérifie l'état de la sonde ICMP non seulement sur les routes de transfert statiques de la passerelle partenaire, mais aussi sur les routes BGP. Si l'état d'une sonde est inactif, le dispositif Edge marque la route de transfert statique et les routes BGP comme étant inactives, ce qui entraîne une interruption du trafic client.

• Problème résolu 106913 : Les routes externes du Hub ne sont pas annoncées à une destination non-SD-WAN via une passerelle via BGP sur une passerelle VMware SD-WAN Gateway.

  Ce problème est dû à un comportement hérité de BGP sur une passerelle partenaire. Le BGP de transfert a volontairement évité de redistribuer les routes externes du HUB OSPF dans un BGP PG afin d'éviter une boucle, et le BGP NSD a hérité de ce comportement de BGP PG.

• Problème résolu 107114 : Lorsqu'une console série d'un dispositif VMware SD-WAN Edge est désactivée à partir des paramètres de pare-feu sur VMware SASE Orchestrator, un utilisateur peut continuer à voir des messages sur la console série.

  SD-WAN ne supprime pas les messages de routine de la console, même lorsque la console série est désactivée dans Orchestrator. Le correctif ici garantit que le dispositif Edge n'imprime que les messages critiques (CRIT, ALERT, EMERG) sur la console série lorsqu'elle est désactivée dans les paramètres du pare-feu.

• Problème résolu 107216 : Lors de l'exécution du diagnostic à distance « État de l'interface » (Interface Status), la sortie affiche une vitesse de lien inexacte.

  Lorsqu'une interface est sélectionnée pour la négociation automatique « désactivée » (off), l'interface ne s'exécute plus sous DPDK avec un pilote Silicon. Le nouveau pilote utilisé pour DPDK est « af_packet », qui exploite le pilote de noyau sous-jacent. La nouvelle vitesse manuelle n'est pas définie après l'annulation de la liaison PCI de DPDK au noyau. Suite à la vitesse de lien lors de l'exécution de la commande de débogage ethtool utilisée par l'état de l'interface (Interface Status), le résultat est inexact.

• Problème résolu 107309 : Lorsqu'un client configure le contrôle de santé L7 pour une destination non-SD-WAN via un dispositif Edge sur un dispositif Orchestrator 4.x et qu'Orchestrator est mis à niveau vers la version 5.x, le dispositif Edge n'applique pas la nouvelle valeur si le client tente de modifier la valeur de nouvelle tentative de sonde L7.

  Par exemple, si la valeur de nouvelle tentative de sonde de contrôle de santé L7 est de 3 (le tunnel est marqué comme étant inactif sur 3 sondes défaillantes) et que le client passe cette valeur à 1, le contrôle de santé L7 continue d'utiliser la valeur d'origine de 3 nouvelles tentatives avant que le tunnel ne soit marqué comme étant inactif.

• Problème résolu 107317 : pour un client utilisant SNMP sur lequel le serveur se trouve sur Internet, une collecte SNMP peut réussir pour certaines interfaces de dispositif VMware SD-WAN Edge et échouer après un délai d'expiration sur d'autres interfaces.

  Lorsque la collecte SNMP échoue, la demande SNMP entre dans une interface, mais sort d'une autre interface et ces paquets de réponse n'atteignent jamais le serveur SNMP. Ce problème est dû au fait que le dispositif Edge classe de manière incorrecte le trafic SNMP de telle sorte qu'il dirige ces paquets vers une interface différente pour les paquets de réponse, quelle que soit l'interface utilisée pour la réception. Par conséquent, les collectes SNMP fonctionnent pour l'interface que le dispositif Edge désigne pour la réponse SNMP, mais elles échouent pour toutes les autres.

• Problème résolu 107708 : Sur un dispositif VMware SD-WAN Edge sur lequel la limite de débit d'overlay SD-WAN est configurée, il se peut que la passerelle SD-WAN Gateway ne respecte pas strictement la limite lorsque le trafic descendant circule d'Internet vers le dispositif Edge.

  Le débit du trafic circulant d'Internet vers le dispositif Edge n'est pas limité par la passerelle selon la configuration exacte. La limite d'overlay SD-WAN est dépassée de quelques Mbits/s. Cela se produit, car le temps système (de gestion) de VCMP n'est pas pris en compte dans la passerelle pour calculer la limite du débit.

• Problème résolu 107994 : Lorsque des utilisateurs disposant d'un accès sécurisé au dispositif Edge et de privilèges sont provisionnés, les opérations liées à la haute disponibilité, telles que l'exécution du diagnostic à distance « Informations sur HA » (HA Info) à partir d'Orchestrator et la connexion au dispositif Edge HA peer échouent.

  Lorsque des utilisateurs disposant d'un accès au dispositif Edge sécurisé et de privilèges sont provisionnés, le compte racine est complètement bloqué. Le problème est dû au fait que les opérations HA reposent sur la communication avec le dispositif Edge peer en tant que racine. Les opérations HA effectuées après coup ne fonctionnent pas alors.

  Sur une paire de dispositifs Edge HA sans correctif pour ce problème, le client doit revenir à l'authentification par mot de passe et supprimer tous les utilisateurs disposant d'un dispositif Edge de Secure Access et de privilèges OU les passer en utilisateurs de base.

• Problème résolu 108374 : Pour une entreprise cliente qui utilise un système dynamique site distant vers site distant et qui a configuré des règles NAT côté LAN, un changement de route peut entraîner l'échec du trafic vers un LAN distant.

  Lors d'un changement de route, tel que des tunnels dynamiques site distant vers site distant, la NAT côté LAN peut ne pas être correctement recalculée pour les flux existants, ce qui entraîne leur arrêt et a une incidence sur le trafic destiné à un sous-réseau LAN de dispositif Edge peer.

• Problème résolu 108473 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données, déclencher un noyau et redémarrer pour récupérer le service.

  La passerelle peut se trouver dans une situation dans laquelle il existe un dépassement de nombre de séquences, ce qui déclenche la suppression de toutes les SA (associations de sécurité IPsec). Lors d'une tentative de suppression de toutes les SA, le processus de passerelle tente de trouver un tunnel basé sur un ID de tunnel, mais le tunnel n'existe pas, ce qui entraîne l'échec du service de passerelle.

• Problème résolu 108610 : Pour une entreprise cliente dans laquelle le pare-feu est activé, le pare-feu bloque le trafic qui ne l'a pas été auparavant lorsque le dispositif Edge est mis à niveau de la version 3.x vers une version 4.x.

  Lorsqu'Orchestrator est déplacé vers la version 4.2.2 dans la séquence suivante : De la version 3.4.4 vers la version 4.0.0 et de la version 4.0.2 vers la version 4.2.2, la configuration du groupe d'adresses ne reflète pas les dispositifs Edge connectés à ce dispositif Orchestrator qui sont d'une version 3.4.4 d'Edge vers la version 4.2.2 d'Edge. En raison du fait que le dispositif Edge attend une version différente du fichier JSON des groupes d'adresses dans les versions 3.4.4 et 4.2.2, Orchestrator qui a été mis à niveau dans la séquence ci-dessus n'envoie pas les fichiers JSON aux dispositifs Edge dans le nouveau format tant qu'il n'existe pas une modification de la configuration. Par conséquent, les configurations des groupes d'adresses ne fonctionnent pas.

• Problème résolu 108982 : Pour un dispositif VMware SD-WAN Edge sur lequel les sondes ICMP (ICMP Probes) sont configurées, le client peut observer que les sondes du périphérique Edge (Edge Probes) cessent de fonctionner avec un état INIT.

  Le temporisateur de la sonde ICMP peut devenir endommagé, ce qui entraîne le blocage de la machine d'état de la sonde dans l'état INIT. La corruption du temporisateur est due à une condition de concurrence lorsque plusieurs threads tentent d'ajouter le temporisateur, de le supprimer ou de l'arrêter.

• Problème résolu 109500 : Lorsque la NAT côté LAN utilise la même définition interne et externe, le premier paquet d'un flux direct est abandonné.

  Le problème est dû au fait que les informations de correspondance dans la table NAT d'origine sont les mêmes pour la traduction NAT côté LAN initiale et pour la traduction NAT directe. Cela entraîne un conflit dans les tables qui annule le premier paquet.

• Problème résolu 109511 : Lorsqu'un dispositif VMware SD-WAN Edge rencontre le nombre maximal de tunnels, l'événement EDGE_TUNNEL_CAP_WARNING peut ne pas s'afficher sur VMware SASE Orchestrator.

  Le dispositif Edge n'envoie pas de message à Orchestrator pour un avertissement de limite de tunnels lorsque le problème se produit pour la première fois dans une période de 24 heures.

• Problème résolu 109963 : Un utilisateur ne peut pas se connecter via SSH à un dispositif VMware SD-WAN Edge virtuel.

  Tous les types de dispositifs Edge virtuels (Azure, AWS, etc.) sont affectés par ce problème. Lorsqu'une tentative de connexion via SSH est effectuée, le dispositif Edge virtuel reçoit deux paquets SSH, ce qui amène le noyau Edge à répondre à deux demandes SSH, provoquant la confusion du client SSH et l'échec de la connexion SSH.

• Problème résolu 110406 : Pour un site client déployé avec une topologie à haute disponibilité, le dispositif Edge actif peut ne pas terminer la rétrogradation si la paire de dispositifs Edge HA est rétrogradée vers une version antérieure du logiciel.

  Lorsque ce problème se produit, seul le dispositif Edge passif est mis à niveau vers la version logicielle spécifiée alors que le dispositif Edge actif ne rétrograde jamais, ce qui signifie que le site est effectivement un site autonome et qu'il n'est plus à haute disponibilité (HA).

  Sur un site HA sur lequel ce problème se produit sans correctif, la solution consiste à désactiver HA, à rétrograder le dispositif Edge actif précédent comme instance autonome, puis à réactiver HA avec les deux dispositifs Edge désormais sur la même version rétrogradée.

• Problème résolu 110456 : la sonde ICMP d'une passerelle de partenaires ou d'une passerelle de cloud vers un périphérique directement attaché peut abandonner des paquets si le champ de code de demande ICMP n'est pas 0.

  Selon le fournisseur, certains peuvent inspecter le champ de code pour rechercher un paquet de demande ICMP et le juger incorrect si le champ n'est pas 0.

• Problème résolu 110473 : Pour une entreprise cliente utilisant BGP, des routes inattendues sont reçues/envoyées momentanément et les flux peuvent correspondre à des Business Policies incorrectes lorsqu'un BGP Neighbor est supprimé.

  Lorsqu'un BGP Neighbor est supprimé d'Orchestrator, les cartes de routes entrantes/sortantes qui lui sont associées sont d'abord supprimées, puis le Neighbor est supprimé de la configuration de routage du dispositif Edge. Cela entraîne une fuite momentanée de routes refusées par ces cartes de routes. Cela affecte à son tour le comportement de la business policy si un flux est créé avec les routes divulguées.

  Sur un dispositif Edge sans correctif pour ce problème, un utilisateur peut exécuter le diagnostic à distance « Vider les flux » (Flush Flows) pour corriger le problème.

• Problème résolu 110484 : un client peut observer un état de chemin incorrect sur la page Dispositif Edge (Edge) > Surveiller (Monitor) > Chemins (Paths) d'Orchestrator si le chemin est associé à un lien WAN sur lequel la détection MTU du chemin a été désactivée.

  Le client peut également observer deux états de chemin différents pour le même chemin sur la page Surveiller (Monitor) > Chemins (Paths) pour les points de terminaison Edge de ce chemin. Ce comportement est dû au fait que la configuration du lien de détection MTU de chemin ne fonctionne pas comme prévu par rapport aux overlays WAN détectés automatiquement. Cette configuration est généralement traitée dans la fonction de mise à jour de la configuration, car le dispositif Edge déclenche la configuration du lien pour Orchestrator avec ces types de liens. Toutefois, ce problème s'explique par une mise à jour de la configuration PMTU manquante lors de l'appel de mise à jour.

  Note:

  Les symptômes de ce problème ne sont pas résolus pour ce ticket et un client peut les rencontrer comme indiqué ci-dessus. Une build qui inclut ce ticket ajoute des améliorations de journalisation qui aident l'équipe d'ingénierie à fournir un correctif réel.

• Problème résolu 110564 : Pour un site client déployé dans une topologie à haute disponibilité, la session TCP utilisée pour synchroniser les données entre les dispositifs Edge actif et passif peut s'arrêter. Sur un déploiement HA améliorée, le trafic de lien WAN n'est ainsi pas transféré sur le dispositif Edge passif.

  Pour les déploiements HA standard ou HA améliorée, il peut exister un scénario dans lequel un processus enfant utilise le port destiné aux sessions TCP entre le dispositif Edge actif et le dispositif Edge passif. Dans ce scénario, le dispositif Edge actif ne peut pas activer le serveur TCP en raison d'erreurs de liaison, et l'état de l'interface du dispositif Edge passif n'est donc pas échangé. Pour les déploiements HA améliorée, le ou les liens WAN ne peuvent donc pas être utilisés pour le transfert du trafic.

• Problème résolu 111073 : Un dispositif VMware SD-WAN Edge utilisant la version 4.5.1 peut signaler une vitesse d'interface incorrecte à SNMP.

  ifSpeed est une valeur de 32 bits. Si elle ne peut pas contenir la valeur de la vitesse donnée par le dispositif Edge en bits par seconde (bits/s), il est recommandé de se reporter à ifHighSpeed qui indique la valeur en Mbits/s.

• Problème résolu 111162 : Dans une entreprise cliente qui utilise une passerelle partenaire et déploie des dispositifs Edge en haute disponibilité, un dispositif Edge HA peut disposer d'un routage inefficace lorsqu'une route PG est sélectionnée comme meilleure route via une passerelle partenaire secondaire.

  Dans le dispositif Edge HA, en cas de transitions A-A ou A-S, il est possible que l'ordre d'une route PG d'une passerelle partenaire secondaire soit défini sur 4 : elle devient ainsi la meilleure route. En général, les routes de la passerelle partenaire principale présentent des valeurs d'ordre plus élevées.

• Problème résolu 111314 : Sur une entreprise cliente dans laquelle le calcul du coût dynamique (Dynamic Cost Calculation) est activé, des abandons de trafic peuvent s'observer.

  Ce problème peut se produire si l'un des dispositifs Edge annonce des routes plus spécifiques à tous les dispositifs Edge de l'entreprise avant d'être déconnecté. Une fois que ce dispositif Edge est hors ligne, les routes sont conservées dans la FIB de tous les autres dispositifs Edge avec accessibilité = False, ce qui entraîne des abandons de paquets.

  Sur un dispositif Edge sans correctif pour ce problème, un utilisateur peut corriger le problème en lançant manuellement un redémarrage du service Edge via le menu Actions à distance (Remote Actions) d'Orchestrator.

• Problème résolu 111646 : Une passerelle VMware SD-WAN Gateway sous une charge de CPU élevée peut subir une panne du service de plan de données et redémarrer pour reprendre.

  Un utilisateur examinant un noyau généré par la passerelle observe l'exception de moniteur mutex et le message Program terminated with signal SIGXCPU, CPU time limit exceeded message. Ce problème est lié au fait qu'un processus de passerelle libère un verrou thread de plus faible priorité.

• Problème résolu 111840 : pour une entreprise cliente utilisant plus de 8 dispositifs VMware SD-WAN Edge configurés comme Hubs, les utilisateurs peuvent observer de faibles performances du trafic en raison d'un routage inefficace.

  Lorsqu'un dispositif Spoke Edge est configuré avec plusieurs dispositifs Hub Edge, la route via le Hub est préférée à une route directe entre deux sites distants, ce qui entraîne un routage inefficace.

  Sur les dispositifs Edge sans correctif pour ce problème, vous pouvez configurer les dispositifs Hub Edge, suivis des dispositifs Hub Edge de VPN dans la liste de sites du site distant vers le Hub.

• Problème résolu 111888 : Une passerelle VMware SD-WAN Gateway déployée avec 4 cœurs et plus de 2 000 tunnels qui y sont connectés peut subir une utilisation élevée du CPU et les tunnels connectés à la passerelle peuvent être instables.

  L'un des threads de passerelle puise trop sur le CPU dans une passerelle à 4 cœurs, ce qui entrave la capacité de la passerelle à maintenir des tunnels stables.

• Problème résolu 111924 : Un client peut observer que sur tous ses sites, le trafic à chemins multiples (c'est-à-dire, le trafic qui traverse la passerelle VMware SD-WAN Gateway) est abandonné, même si les tunnels du dispositif VMware SD-WAN Edge vers la passerelle sont actifs et stables.

  Il n'existe aucune limite sur le nombre maximal de retransmissions d'un paquet VCMP (protocole de gestion de SD-WAN) par une passerelle, et ces retransmissions peuvent surcharger les liens à bande passante faible. Ces retransmissions entraînent également une accumulation de paquets sur le planificateur lorsque le dispositif Edge dispose d'un lien à bande passante faible, car les retransmissions ne peuvent pas être purgées suffisamment rapidement. Les files d'attente du planificateur finissent par se saturer et entraîner l'abandon de paquets de tous les dispositifs Edge par le planificateur. Ce problème n'a pas d'incidence sur le trafic direct qui n'utilise pas la passerelle.

  Lorsque ce problème se produit sur une passerelle sans correctif pour ce problème, la seule façon de le résoudre consiste à permettre à un utilisateur opérateur d'identifier les dispositifs Edge qui entraînent l'accumulation de paquets sur le planificateur à l'aide de la commande debug.py --qos_dump_net et de les bloquer dans la passerelle concernée.

• Problème résolu 111935 : Un dispositif VMware SD-WAN Edge configuré comme un Hub peut ne pas apprendre les routes à partir d'un site distant.

  Lorsque deux dispositifs Edge pointent l'un vers l'autre comme Hubs, il est possible que l'un d'entre eux apprenne les routes de l'autre dispositif Edge.

  Sur les dispositifs Edge sans correctif pour ce problème, un client peut résoudre ce problème en arrêtant la configuration du Hub de maillage et en regroupant tous les dispositifs Hub Edge dans un seul profil avec le VPN cloud activé uniquement.

• Problème résolu 112016 : Après un redémarrage, une passerelle VMware SD-WAN Gateway peut subir plusieurs pannes de service de plan de données avec des cœurs générés.

  Lors de l'examen des cœurs, un opérateur observe le déclenchement de chaque panne en raison d'un problème de moniteur mutex. Il y a une augmentation notable du temps du traitement VCMP (protocole de gestion de SD-WAN) effectué pour le thread qui le gère. Lors du démarrage d'une passerelle, cela entraîne l'exécution continue du thread VCMP à 100 % pendant de longues périodes (plus de 60 secondes), ce qui cause plusieurs pannes du service de passerelle liées au moniteur mutex.

• Problème résolu 112017 : Un opérateur peut observer qu'une passerelle VMware SD-WAN Gateway déployée avec 4 cœurs subit une charge élevée entraînant une ou plusieurs pannes d'un service de plan de données.

   Les journaux de cœurs de la passerelle pointent vers le moniteur mutex qui déclenche la panne du service. Plusieurs tickets corrigent le symptôme ci-dessus et, dans le cas présent, la cause provient des threads VCMP (protocole de gestion) qui augmentent les processus CPU de la passerelle à 4 cœurs, ce qui déclenche le moniteur mutex. Ce ticket ajoute la possibilité de permettre à un utilisateur opérateur de configurer une limite de connexions semi-ouvertes VCMP de 20. Cette opération peut s'effectuer via l'interface de ligne de commande (CLI) de la passerelle à l'aide de debug.py ou par un fichier de configuration statique.

• Problème résolu 112019 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données et redémarrer pour reprendre sous une charge de CPU élevée.

  Comme avec les autres tickets de panne du service de passerelle dans la build cumulative 5.1.0.3, l'opérateur ou le partenaire observe un déclencheur de moniteur mutex dans le fichier noyau. Avec ce ticket, vous pouvez corriger le problème en déplaçant les journaux de débogage NAT en dehors de la portée de verrouillage de la table NAT afin d'éviter l'une des causes de ce problème.

• Problème résolu 112020 : Une passerelle VMware SD-WAN Gateway déployée avec 4 cœurs sous une charge de CPU élevée peut subir une panne du service de plan de données et redémarrer en conséquence.

  En examinant le fichier noyau de la passerelle, un utilisateur observe une panne du moniteur mutex causée par une incapacité d'exécution du processus de passerelle, car le CPU s'exécute à une capacité maximale en raison d'un nombre élevé de tunnels.

• Problème résolu 112452 : Un client peut observer qu'un dispositif VMware SD-WAN Edge qui configure la haute disponibilité rencontre des boucles L2 sur les interfaces WAN du dispositif Edge.

  Lorsqu'une interface passe de commutée à routée, un problème se produit avec l'adresse MAC dans le fichier origmacs. Si une adresse MAC virtuelle est stockée pour une interface ou si aucune adresse MAC d'origine pour l'interface n'est stockée dans le fichier, le dispositif Edge finit par utiliser l'adresse MAC virtuelle pour envoyer des pulsations WAN, ce qui entraîne la détection d'une boucle L2.

  Sur un dispositif Edge HA sans correctif pour ce problème, la solution consiste à demander au support de supprimer le fichier origmacs, puis de redémarrer d'abord le dispositif Edge HA passif, puis le dispositif Edge HA actif.

• Problème résolu 112800 : Les clients utilisant une passerelle VMware SD-WAN Gateway peuvent rencontrer de faibles performances, notamment un délai de convergence plus long pour les tunnels et les routes.

  Lors de l'examen de la surveillance d'une passerelle, un utilisateur observe que les cœurs du plan de données (dp-cores) s'exécutent à 100 % en raison de la non-suppression des flux de répartition des flux périmés par la passerelle.

• Problème résolu 112882 : Lorsqu'un dispositif VMware SD-WAN Edge est mis à niveau vers la version 5.1.0.3, SNMP peut cesser de fonctionner sur le dispositif Edge.

  Toutes les modifications apportées au tableau segnat SNMP des entrées ne comportent pas d'appel API « Mise à jour » (Update) correspondant. Cela entraîne le blocage de l'adresse IP/du port de destination correspondant(e).

• Problème résolu 113153 : pour une entreprise cliente déployée avec une topologie à haute disponibilité, le dispositif VMware SD-WAN Edge dans le rôle actif peut subir une panne du service de plan de données qui déclenche un basculement HA, lorsque le dispositif Edge passif est redémarré.

  Lorsque le dispositif Edge actif subit une panne du service de plan de données, cela déclenche également un basculement HA. Ce problème peut se produire lorsque le site HA transfère une grande quantité de trafic.

• Problème résolu 114004 : Un client peut observer qu'un dispositif VMware SD-WAN Edge subit une fuite de mémoire si SNMP est configuré sur le dispositif Edge.

  La fuite de mémoire du dispositif Edge est lente, mais si elle n'est pas résolue et atteint un niveau critique d'utilisation de la mémoire, le dispositif Edge déclenche préventivement un redémarrage de service pour effacer la mémoire. Ce redémarrage peut perturber le trafic client pendant 15 à 30 secondes lors de la reprise du dispositif Edge et, sans correctif pour ce problème, la fuite de mémoire se reproduit.

• Problème résolu 114052 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données, déclencher un noyau et redémarrer en conséquence.

  Ce problème est dû à l'expiration d'un processus IPsec de la passerelle et au déclenchement d'une panne de service de passerelle.

• Problème résolu 114084 : Pour un client qui a configuré un service de sécurité cloud (CSS) de type Zscaler avec un contrôle de santé L7 pour un dispositif VMware SD-WAN Edge, lors de la mise à jour du serveur cloud Zscaler sur VMware SASE Orchestrator, les informations mises à jour ne sont pas appliquées au dispositif Edge.

  Bien qu'Orchestrator affiche la nouvelle configuration du serveur cloud Zscaler, le dispositif Edge et la passerelle n'envoient pas de trafic ou les sondes L7 via ce nouveau serveur, mais via l'ancien serveur Zscaler.

• Problème résolu 114282 : Lorsqu'une passerelle VMware SD-WAN Gateway déployée avec 4 cœurs est redémarrée, la convergence de 3 000 tunnels pour les entreprises clientes connectées peut prendre jusqu'à vingt minutes.

  Il est prévu qu'une passerelle fasse converger approximativement 3 000 tunnels en environ 5 minutes par rapport aux vingt minutes observées dans ce problème. Un taux plus lent entraînerait une interruption du trafic client jusqu'à la restauration complète des tunnels. La cause de la convergence plus lente est liée à une configuration dans le processus IPsec de la passerelle qui gère les associations et les clés de sécurité, qui est corrigée avec ce ticket.

• Problème résolu 114511 : Pour un lien WAN détecté automatiquement, la désélection de l'option Détection MTU du chemin (Path MTU Discovery) ne fonctionne pas et le dispositif Edge continue d'appliquer la fonctionnalité et de redimensionner la MTU.

  La configuration est traitée lors d'une mise à jour des liens détectés automatiquement et cette configuration spécifique de la MTU du chemin n'a pas été traitée lors de la mise à jour de la configuration.

• Problème résolu 114932 : Les performances du trafic des utilisateurs peuvent être dégradées en cas de connexion à une passerelle VMware SD-WAN Gateway.

  Les utilisateurs opérateurs peuvent observer une utilisation élevée du CPU pour la passerelle, même si le nombre de tunnels se trouve dans les limites prises en charge. L'utilisation élevée du CPU provient du fait qu'une SA (association de sécurité) IKE obsolète reste plus longtemps dans la table IKE et entraîne un délai de convergence plus long des tunnels, ce qui entraîne une augmentation des abandons de trafic et une instabilité des chemins pour le trafic client traversant la passerelle.

• Problème résolu 115078 : Sur une entreprise cliente à grande échelle comportant environ 16 000 utilisateurs et un taux de création de flux d'environ 2 000 par seconde sur les dispositifs Edge Hub, les utilisateurs peuvent rencontrer une faible qualité de trafic en raison d'une latence élevée.

  Le moteur d'inspection approfondie des paquets (DPI) de la passerelle peut être surchargé sur les dispositifs Edge Hub lorsqu'un nombre élevé de flux initiés par un peer est créé. Cela est dû au fait que le cache de port est renseigné avec l'adresse IP source et le numéro de port au lieu de l'adresse IP de destination et du numéro de port pour ces flux peer.

• Problème résolu 115132 : Si un utilisateur exécute le diagnostic à distance « Vidage de la table NAT » (NAT Table Dump) pour un dispositif VMware SD-WAN Edge utilisant la version 5.1.0.2 d'Edge, il peut en résulter des valeurs vides.

  Ce problème empêche les utilisateurs de déboguer les problèmes NAT sur les dispositifs Edge à l'aide de la version 5.1.0.2. Les dispositifs Edge utilisant des versions antérieures fonctionnent comme prévu.

• Problème résolu 115692 : Un opérateur peut observer une augmentation de l'utilisation de la mémoire dans une passerelle VMware SD-WAN Gateway, ce qui peut entraîner un épuisement de la mémoire et un redémarrage préventif du service pour effacer la mémoire.

  Dans ce cas, la passerelle subit une fuite de mémoire IKE de la passerelle renouvelant les certificats avec les sites peer.

  Sans correctif pour ce problème, l'opérateur peut uniquement surveiller l'utilisation de la mémoire sur la passerelle et redémarrer de manière proactive la passerelle dans une fenêtre de maintenance qui garantit la moindre interruption des sites clients utilisant la passerelle.

• Problème résolu 116086 : pour un dispositif VMware SD-WAN Edge utilisant une version 5.0.x ou 5.1.x (pré-activation de l'image d'usine ou post-activation), lorsque vous utilisez l'interface utilisateur locale, l'option de configuration d'une interface routée avec un ID VLAN n'est pas présente.

  Ce problème empêche un utilisateur de configurer un VLAN sur une interface routée avant l'activation du dispositif Edge si celui-ci utilise une image d'usine 5.0.x ou 5.1.x ou s'il est activé et utilise l'une des versions d'Edge dans les trains 5.0.x et 5.1.x. Seule une image d'usine version 5.2.0 ou ultérieure dispose du correctif de ce problème avant l'activation.

• Problème résolu 116182 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données et déclencher un cœur, puis redémarrer en conséquence.

  Ce problème se produit sur les passerelles dans lesquelles les dispositifs SD-WAN Edge connectés sont configurés avec une stratégie de backhaul Internet en mode mixte IPv6 ou IPv4/IPv6 vers une destination non-SD-WAN (NSD) via une passerelle. Dans ce scénario, lorsque la passerelle reçoit des paquets IPv6 destinés à une NSD utilisant IPv4, cela déclenche la panne du service de passerelle.

• Problème résolu 116589 : Lorsqu'un dispositif VMware SD-WAN Edge est mis à niveau de la version 3.x vers la version 4.x ou une version plus récente, les groupes d'adresses configurés ne sont pas analysés dans certains cas.

  Dans la version 3.x, aucune configuration ne permet de définir isakmpLifeMins et ipsecLifeMins. Par conséquent, lorsqu'un dispositif Orchestrator exécute la version 3.x, il envoie un fichier de configuration de propriété Edge sans isakmpLifeMins et ipsecLifeMins.

  Lorsqu'Orchestrator est mis à niveau vers la version 4.x et des versions ultérieures, il contient les champs isakmpLifeMins et ipsecLifeMins, mais cette configuration n'est pas transférée vers le dispositif Edge 3.x. Si le dispositif Edge est également mis à niveau de la version 3.x vers la version 4.x et versions ultérieures, le dispositif Edge commence à mettre en place la dernière configuration correcte connue (qui n'inclut pas isakmpLifeMins et ipsecLifeMins).

  Lorsque le dispositif Edge démarre, il découvre que isakmpLifeMins et ipsecLifeMins, qui sont des paramètres obligatoires, ne sont pas présents. Il arrête donc le traitement du fichier de configuration de propriété Edge. Aucune des autres configurations de ces fichiers, telles que les groupes d'adresses, ne sera ainsi traitée après cette configuration spécifique. Par conséquent, la configuration du groupe d'adresses est absente.

• Problème résolu 116641 : Les journaux VMware SD-WAN Edge contiennent des journaux d'échec de la recherche de routes avec le motif d'erreur « Aucune » (None).

  Lorsque le trafic échoue, le client peut parfois voir les journaux d'échec de la recherche de routes avec le motif d'erreur « Aucune » (None), ce qui ne fournit aucune valeur pour résoudre le problème. Le correctif fournit une raison qui aide l'utilisateur à résoudre le problème.

  Par exemple, auparavant, le fichier journal des échecs ressemblait à :

  20:40:41.796089,856|7|6825/10072|edged_ipv4_route_lookup_vcmp_transit:6880 Route lookup failure for tuple src_ip=10.0.1.25 dst_ip=169.254.6.18 segment_id=0 lookup failed due to [None]

  Dans la version 4.5.2, il ressemble à cela (la partie en gras est modifiée) :

  04:07:35.464563,968|7|9720/1917413|edged_ipv4_route_lookup_vcmp_transit:6958 Route lookup failure for tuple src_ip=10.0.1.25 dst_ip=169.254.6.18 segment_id=0 sroute=(nil) droute=(nil) lookup failed due to [No src and dst route]

Problèmes d'Orchestrator résolus

• Résolu dans la version R5204-20230831-GA d'Orchestrator
• Résolu dans la version R5203-20230809-GA d'Orchestrator
• Résolu dans la version R5202-20230729-GA d'Orchestrator
• Résolu dans Orchestrator version R5201-20230623-GA
• Résolu dans R5200-20230529-GA

Résolu dans la version R5204-20230831-GA d'Orchestrator

La build R5204-20230831-GA d'Orchestrator a été publiée le 01/09/2023 et constitue la 4e build cumulative d'Orchestrator pour la version 5.2.0.

Cette build cumulative d'Orchestrator résout les problèmes critiques ci-dessous depuis la 3e build cumulative R5203-20230809-GA d'Orchestrator.

• La build R5204-20231201-GA de l'interface utilisateur a été publiée le 04/12/2023 et constitue la 12e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator. 

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 126695	Sur la page SD-WAN > Paramètres (Settings) > Alertes (Alerts) > Webhooks de l'interface utilisateur, si un utilisateur configure des Webhooks pour des alertes, le menu ne s'affiche pas lorsqu'il clique sur le bouton Configurer le modèle de charge utile (Configure Payload Template).
  Problème résolu n° 128921	Un super utilisateur partenaire ou d'entreprise accédant à la page SD-WAN > Entreprise (Enterprise) > Paramètres de service (Service Settings) constate qu'il n'existe aucune option pour afficher les licences Edge.
  Problème résolu n° 131224	Sur la page Configurer (Configure) > Périphérique (Device) > Services VPN (VPN Services) de l'interface utilisateur, lors de la configuration d'un service Zscaler, le nom de sous-emplacement Autre (Other) peut être modifié. Orchestrator marque alors la configuration comme non valide et génère les erreurs « Les sous-emplacements Zscaler ne peuvent pas être nommés comme 0 (Zscaler sublocations cannot be named as 0) » et « Impossible d'enregistrer les modifications. Votre configuration comporte une ou plusieurs erreurs. (Cannot save changes. There is one or more errors within your configuration.) ». Le sous-emplacement Autre (Other) ne doit jamais être modifié. Ce problème se produit uniquement si le service Zscaler est désactivé, puis réactivé.
  Problème résolu n° 131631	Sur la page Surveiller (Monitor) > Edge > Destinations, un utilisateur ne peut pas filtrer par Applications, car cette option n'est pas présente dans l'interface utilisateur.
  Problème résolu n° 132047	Sur la page Configurer (Configure) > Edge > Périphérique (Device) > Connectivité (Connectivity) > VLAN de l'interface utilisateur, lorsque l'utilisateur choisit l'option VLAN DHCP 2 (Décalage de temps [Time Offset]), il ne peut pas entrer de valeur négative, même s'il s'agit d'un entier. Le comportement attendu est que l'interface utilisateur autorise les entiers positifs et négatifs.
  Problème résolu n° 132384	Après une modification de la configuration effectuée sur un VLAN au niveau du profil, toutes les données associées à DHCP ou OSPF sur tous les dispositifs Edge utilisant ce profil sont perdues si la configuration utilise un remplacement du dispositif Edge.
  Problème résolu n° 133008	Sur la page Surveiller (Monitor) > Présentation du réseau (Network Overview) de l'interface utilisateur, si les dispositifs Edge sont triés par état de la liaison (par exemple, Liaisons inactives [Links down], Liaisons stables [Links stable] ou Liaisons dégradées [Links degraded]), l'option Actualisation automatique (Auto-Refresh) ne fonctionne pas et toutes les informations de surveillance disparaissent de l'interface utilisateur.

• La build R5204-20231121-GA de l'interface utilisateur a été publiée le 22/11/2023 et constitue la 11e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

   Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 128017	Un client qui tente d'accéder à la page Configurer (Configure) > Edge > Périphérique (Device) peut constater qu'elle ne se charge jamais, car l'interface utilisateur a supprimé par erreur les références de configuration du dispositif Edge de la base de données Orchestrator. Une fois ces références supprimées, elles ne peuvent pas être restaurées.
  Problème résolu n° 129695	Si un utilisateur partenaire modifie le mot de passe Wi-Fi d'un dispositif Edge sur son interface WLAN et enregistre les modifications, un utilisateur opérateur voit l'ancien mot de passe Wi-Fi lorsqu'il consulte l'interface WLAN du même dispositif Edge.
  Problème résolu n° 130810	Un utilisateur ne peut pas insérer de règle de filtre BGP dans une liste de ces règles (au-dessus ou entre deux règles ou plus). Une règle de filtre BGP ne peut être ajoutée qu'à la fin de la liste.
  Problème résolu n °131138	Sur la page Configurer (Configure) > Périphérique (Device) > VPN > VPN cloud (Cloud VPN), l'interface utilisateur permet à un utilisateur d'enregistrer une modification dans l'option Hubs de VPN site distant vers site distant (Branch to VPN Hubs) si aucun Hub n'est configuré. Cela entraîne la suppression de toutes les configurations VPN cloud par l'interface utilisateur, car le fichier de configuration est endommagé.
  Problème résolu n° 132524	Sur la page Configurer (Configure) > Edge > Périphérique (Device) > Routage et NAT (Routing & NAT) > Paramètres de route statique (Static Route Settings) de l'interface utilisateur, lorsqu'un utilisateur ajoute une route statique à un dispositif Edge pour lequel l'adresse IP next-hop de la route statique se trouve dans le même sous-réseau du réseau VLAN, l'interface utilisateur affiche les interfaces Edge alors que les paramètres Interface des routes locales devraient passer à S/O (N/A).

• La build R5204-20231115-GA de l'interface utilisateur a été publiée le 16/11/2023 et constitue la 10e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 123078	Lors de l'accès à la page Surveiller (Monitor) > Dispositif Edge (Edge) > Présentation (Overview), les colonnes ne sont pas alignées correctement, car aucune information n'est renseignée pour la colonne Numéro de série du périphérique (Device Serial No), ce qui entraîne un problème de lisibilité.
  Problème résolu n °123718	Lorsqu'un utilisateur modifie une règle de Business Policy dans l'interface utilisateur d'Orchestrator, il ne peut pas entrer un ID de VLAN personnalisé pour la Business Policy, car l'option VLAN dans l'interface utilisateur est une liste déroulante d'interfaces VLAN, plutôt qu'une entrée de zone de texte.
  Problème résolu n °128330	Pour une entreprise utilisant un service réseau de destination non-SD-WAN (NSD) via une passerelle, l'interface utilisateur permet à l'utilisateur de supprimer une NSD via une passerelle d'un profil qui inclut une règle de Business Policy associée au segment global. Par conséquent, la règle de Business Policy devient non valide et tout trafic correspondant à cette règle n'est pas dirigé comme prévu.
  Problème résolu n° 128765	Sur la page Filtres BGP (BGP Filters), le bouton Envoyer (Submit) peut être inaccessible lorsqu'un utilisateur change de page. Lorsqu'un utilisateur modifie le tableau Filtres BGP (BGP Filters) et accède à une autre page alors qu'un état de configuration n'est pas valide sur la page actuelle, les contrôles de l'interface utilisateur restent grisés et inaccessibles lorsqu'il revient en arrière, même si l'utilisateur renseigne désormais les informations correctes pour cette ligne. Sur une instance d'Orchestrator sans correctif pour ce problème, un utilisateur doit rester sur la page du tableau Filtres BGP (BGP Filters) et s'assurer que toutes les configurations sont correctes avant de la quitter, ou supprimer la ligne non valide et la rajouter ultérieurement.
  Problème résolu n° 130877	Lorsqu'un utilisateur ajoute une route statique à un dispositif Edge à l'aide de l'interface utilisateur d'Orchestrator, les utilisateurs clients de ce dispositif Edge peuvent observer l'échec du trafic pour certaines routes locales. Dans l'interface utilisateur sous Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) > Routage et NAT (Routing & NAT) > Paramètres de route statique (Static Route Settings), les paramètres de l'interface des Routes locales (Local Routes) sont redéfinis en S/O (N/A) et ne peuvent pas être modifiés si l'adresse IP next-hop d'une route statique se trouve dans le même sous-réseau du réseau VLAN. Sans interface configurée, ces routes deviennent inaccessibles.

• La build R5204-20231109-GA de l'interface utilisateur a été publiée le 10/11/2023 et constitue la 9e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n°123387	Un utilisateur ne peut pas ajouter une destination non-SD-WAN (NSD) Zscaler via une passerelle avec une adresse IP existante. La validation d'Orchestrator empêche les utilisateurs d'ajouter un Zscaler avec une adresse IP principale ou secondaire déjà utilisée dans une autre NSD via une passerelle. Note: Ce ticket était initialement répertorié comme étant résolu dans la build R5204-20231013-0631-GA de l'interface utilisateur. Toutefois, ce correctif était incomplet et ce problème n'est entièrement résolu que dans cette build d'interface utilisateur.
  Problème résolu n °123640	Lorsqu'un utilisateur configure des routes statiques pour un dispositif Edge et clique sur le bouton Ajouter (Add) dans la section Routes statiques (Static Routes), une nouvelle ligne vide est ajoutée au tableau, mais l'interface utilisateur génère le message d'erreur « Impossible d'enregistrer les modifications (Cannot save changes) » en bas de l'écran.
  Problème résolu n °127727	Lors de la création d'un service de sécurité cloud (CSS), si un utilisateur active la case Préférence domestique (Domestic Preference) et enregistre la configuration, Orchestrator vérifie les informations d'identification et affiche un message indiquant que « Les modifications ont été enregistrées ! » (Changes saved successfully!). Cependant, après l'enregistrement, lorsque le profil CSS est rouvert, l'utilisateur observe que la case Préférence domestique (Domestic Preference) n'est pas cochée.
  Problème résolu n °129584	Sur la page Configurer (Configure) > Dispositifs Edge (Edges) > Business Policy, lorsqu'un utilisateur modifie une règle de Business Policy existante, l'interface utilisateur ne met pas à jour la valeur reconfigurée du champ Destination, même après l'enregistrement des modifications. Par exemple, pour une règle de Business Policy existante avec Destination définie sur Adresse IP (IP Address), si l'utilisateur redéfinit la valeur de Destination sur Indifférent (Any) et enregistre la modification, les modifications apportées au champ Destination de la règle ne s'appliquent pas dans l'interface utilisateur. L'utilisateur voit toujours le champ Destination défini sur Adresse IP (IP Address) au lieu de l'option Indifférent (Any) dans la règle.
  Problème résolu n °130153	Pour les utilisateurs d'entreprise disposant d'un rôle de support, l'option Redémarrer le service (Restart service) n'est pas disponible sous le menu Surveiller (Monitor) > Dispositifs Edge (Edges) > Sélectionner le dispositif Edge (Select Edge) > Raccourcis (Shortcuts) > Actions à distance (Remote Actions), empêchant ainsi l'utilisateur d'effectuer un redémarrage du service Edge dans le menu Raccourcis (Shortcuts) sur la page Surveiller (Monitor) > Dispositifs Edge (Edges).

• La build R5204-20231101-GA de l'interface utilisateur a été publiée le 2/11/2023 et constitue la 8e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 123001	Après l'activation de la haute disponibilité (HA) et l'enregistrement de la configuration, lorsqu'un utilisateur tente de configurer les paramètres VNF pour le dispositif VMware SD-WAN Edge, la fenêtre Configurer la VNF de sécurité (Configure Security VNF) n'affiche que les champs pour Machine virtuelle principale (VM-1) [Primary Virtual Machine (VM-1)] et les champs pour Machine virtuelle secondaire (VM-2) [Secondary Virtual Machine (VM-2)] ne s'affichent pas. Par conséquent, les utilisateurs doivent actualiser manuellement la fenêtre Paramètres VNF (VNF settings) pour ajouter une adresse IP secondaire à la configuration VNF.
  Problème résolu n° 127904	Lorsqu'un utilisateur crée une route statique et une sonde ICMP sur la même ligne, le dispositif Edge n'installe pas la sonde ICMP et affiche une erreur d'analyse, car l'interface utilisateur envoie l'adresse IP next-hop et la valeur d'adresse IP source comme nulles au lieu d'une chaîne vide au dispositif Edge.
  Problème résolu n° 128753	Lorsqu'un client configure une sous-interface qui utilise DHCP pour l'adressage et crée une définition manuelle de l'overlay WAN, l'utilisateur ne peut pas enregistrer la configuration sans configurer les adresses IP source et next-hop.
  Problème résolu n° 129061	Pour un client avec l'option Transfert aux partenaires (Partner Hand off) activée à partir de l'écran Client (Customer) > Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration) > Configuration supplémentaire (Additional Configuration) > Pool de passerelles (Gateway Pool), vous ne pouvez pas cocher les cases Utiliser pour les tunnels privés (Use for Private Tunnels) et Annoncer l'adresse IP locale via BGP (Advertise Local IP Address via BGP) sous la section IPv6 de l'Interface de transfert (Hand Off Interface) de la passerelle. Cela empêche l'utilisateur de désactiver le tunnel privé IPv6 pour l'interface de transfert.
  Problème résolu n° 129494	Sur la page Client (Customer) > Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration) > Configuration du service (Service Configuration) > SD-WAN, lorsqu'un utilisateur modifie la configuration du service, il doit ajouter le nom de domaine à chaque fois, même si l'authentification Single Sign-On (SSO) ou Edge Network Intelligence (ENI) n'est pas configurée pour le client.
  Problème résolu n° 129765	Lors de la modification d'une interface routée pour un dispositif VMware SD-WAN Edge, l'interface utilisateur remplit une valeur par défaut incorrecte pour dhcpServer.options. Par exemple, lorsqu'un utilisateur modifie l'interface routée « GE3 » et enregistre les données de configuration des paramètres du périphérique, la valeur du champ « options » sous « dhcpServer » est envoyée comme nulle au lieu d'un tableau vide.
  Problème résolu n° 129894	Dans le portail de l'opérateur, lorsque vous examinez Gestion des passerelles (Gateway Management) > Passerelles (Gateways) > Présentation (Overview) > Utilisation du client (Customer Usage), un utilisateur peut observer que certains détails du tunnel du client Edge sont manquants. Ce problème peut se produire si le nom du dispositif Edge, le nom du pool de passerelles et le type de passerelle sont identiques.

• La build R5204-20231027-GA de l'interface utilisateur a été publiée le 27/10/2023 et constitue la 7e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 125964	Pour un client déployant des destinations non-SD-WAN (NSD) via une passerelle, lorsque vous accédez à la page Configurer (Configure) > Services réseau (Network Services) > NSD via la passerelle (NSD via Gateway) > IKEv2 générique (Generic IKEv2) et que vous cliquez sur Enregistrer (Save) après avoir ajouté des sous-réseaux de site personnalisés, les modifications de la configuration de la NSD ne sont pas enregistrées. Ce problème est dû à des champs non valides (Durée de vie de la SA IKE (min) [IKE SA Lifetime(min)] et Durée de vie de la SA IPsec (min) [IPsec SA Lifetime(min)] dans la section Passerelle VPN principale (Primary VPN Gateway).
  Problème résolu n° 126602	Un client ne peut pas ajouter un pool de passerelles à son pool de passerelles de configuration de partenaires existant. Cette tentative renvoie une erreur si le pool de passerelles dans la configuration de partenaires dispose d'un pool géré, car les ID de pools gérés existants ne sont pas supprimés par l'interface utilisateur.
  Problème résolu n° 127904	Lorsqu'un utilisateur crée une route statique et ajoute une sonde ICMP à celle-ci, le dispositif Edge n'installe pas la sonde ICMP et affiche une erreur d'analyse. Ce problème est dû à l'envoi au dispositif Edge de l'adresse IP next-hop et de la valeur de l'adresse IP source comme nulles au lieu d'une chaîne vide d'Orchestrator.
  Problème résolu n° 128279	Sur la page Configurer (Configure) > Overlay Flow Control > Liste de routes (Routes List), un utilisateur peut afficher un maximum de 256 routes sans option pour cliquer sur une page supplémentaire de routes. La limite stricte de 256 routes et l'absence de pagination ont une incidence sur les clients avec de grandes entreprises qui contiennent un nombre de routes bien au-delà de la limite stricte de 256.
  Problème résolu n° 128357	Dans une entreprise cliente qui utilise OSPFv2 ou OSPFv3 pour le routage et sélectionne OE1 dans la liste Route par défaut (Default Route), une option Aucune (None) non valide s'affiche dans la liste Annoncer (Advertise). Les options valides pour Annoncer (Advertise) sont uniquement Toujours (Always) et Conditionnelle (Conditional).
  Problème résolu n° 129413	Lorsqu'un utilisateur configure un VLAN au niveau du dispositif Edge et tente de modifier l'adresse de début DHCP par défaut et enregistre les modifications, l'adresse de début DHCP n'est pas remplacée et l'interface utilisateur d'Orchestrator remplit à nouveau l'ancienne adresse pour le VLAN.
  Problème résolu n° 129926	Lorsqu'un utilisateur provisionne un dispositif Edge sans numéro de série, l'activation du dispositif Edge échoue.

• La build R5204-20231019-GA de l'interface utilisateur a été publiée le 20/10/2023 et constitue la 6e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 127021	Une configuration de destination non-SD-WAN via un dispositif Edge ne s'affiche pas sur l'interface utilisateur lorsqu'elle est configurée à l'aide d'une API d'automatisation, car le script d'automatisation rencontre un problème de corruption des données.
  Problème résolu n° 128706	Sur la page Surveiller (Monitor) > Dispositifs Edge (Edges) > Système (System), lorsqu'un utilisateur tente d'effectuer un zoom dans le graphique, seule une trace noire apparaît, sans action de zoom. Le diagramme répond toujours au sélecteur d'intervalle de temps en haut de la page, il peut donc être utilisé comme solution de contournement.
  Problème résolu n° 129049	Lorsque l'option Remplacement du dispositif Edge (Edge Override) est désactivée, l'option Annonce VLAN (VLAN advertise) de la configuration du dispositif Edge n'utilise pas la valeur d'annonce transférée à partir de la configuration du profil. Même lorsque l'option Annonce VLAN (VLAN advertise) est définie sur false au niveau du profil, lorsque l'option de remplacement est désactivée, l'option Annonce du dispositif Edge (Edge advertise option) n'utilise pas la valeur d'annonce du profil.
  Problème résolu n° 129271	L'option Propriété système (System Property) : vco.enterprise.authentication.passwordPolicy avec le paramètre disallowUsernameCharacters = 3 ne se comporte pas comme prévu. Par exemple, avec le nom d'utilisateur [email protected], l'interface utilisateur vérifie toutes les sous-chaînes : vis, ish, …, t.c, .co, com, comme prévu. Le problème vient du fait que l'interface utilisateur vérifie également : om, m. L'interface utilisateur génère alors une erreur indiquant ce que doit être un mot de passe valide. La solution consiste à redéfinir disallowUsernameCharacters à sa valeur par défaut (-1).
  Problème résolu n° 129560	Sur la page Paramètres de service (Service Settings) > Alertes et notifications (Alerts & Notification), les utilisateurs partenaires et d'entreprise ne peuvent pas modifier le paramètre Activer les alertes d'entreprise (Enable Enterprise Alerts).

• La build R5204-20231013-0631-GA de l'interface utilisateur a été publiée le 13/10/2023 et constitue la 5e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n°120419	Un utilisateur ne peut pas définir une adresse de début DHCP pour un VLAN au niveau du dispositif Edge sans d'abord vérifier le remplacement du dispositif Edge et modifier le nombre d'adresses attribuées par le profil.
  Problème résolu n°127035	Sous Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) > Haute disponibilité (High Availability), après la création d'un Cluster et l'enregistrement des modifications, la page de l'interface utilisateur continue d'afficher la valeur par défaut Aucun (None) même si le cluster a été créé. Il s'agit d'un problème superficiel et une actualisation de la page de l'interface utilisateur affichera la configuration correcte.
  Problème résolu n°127636	Sur la page Surveiller (Monitor) > Dispositif Edge (Edge) > Sources de l'interface utilisateur, la recherche d'une source par nom de domaine complet ne fonctionne pas comme prévu lors de l'utilisation de la nouvelle interface utilisateur, ce qui empêche un utilisateur de localiser une source à l'aide d'une méthode standard. Il est donc impossible de lancer une recherche par chaîne partielle.
  Problème résolu n°127774	Sous Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) > Connectivité (Connectivity) > Interfaces Loopback (Loopback Interfaces), lorsqu'un utilisateur configure une interface Loopback pour un dispositif Edge et enregistre les modifications, la configuration n'est pas appliquée et ne s'affiche pas sur la page de l'interface utilisateur. En outre, l'interface utilisateur n'affiche pas d'erreur pour cet échec, ce qui induit l'utilisateur à penser de manière incorrecte que la modification de la configuration a réussi.
  Problème résolu n°128371	Lorsqu'une destination non-SD-WAN via un dispositif Edge ou un service de sécurité cloud (tel que Zscaler) est désactivé au niveau du profil, le dispositif Orchestrator doit avertir l'utilisateur qu'une business policy est associée à la NSD/CSS afin qu'il puisse réviser la business policy au niveau du dispositif Edge. Sinon, le champ Destination non-SD-WAN via un dispositif Edge/Service de sécurité cloud (Non SD-WAN Destination via Edge/ Cloud Security Service) est vide lorsque l'utilisateur accède au niveau du dispositif Edge et modifie la règle.
  Problème résolu n°128620	Dans Configurer (Configure) > Périphérique (Device) > Services VPN (VPN Services), les profils et les dispositifs Edge n'affichent pas les Hubs connectés dans l'écran de configuration du VPN cloud pour la nouvelle interface utilisateur, même si les dispositifs Edge de site distant se connectent aux Hubs (ce qui peut être confirmé sous Surveiller (Monitor) > Chemins (Paths)).
  Problème résolu n°129253	Sous Paramètres de service (Service Settings) > Alertes et notifications (Alerts & Notifications) > Alertes (Alerts) > Notifications, un utilisateur ne peut pas désactiver SMS comme méthode de notification, car le bouton du curseur est grisé.

• La build R5204-20231003-GA de l'interface utilisateur a été publiée le 04/10/2023 et constitue la 4e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 117923	Lorsqu'un utilisateur provisionne un dispositif Edge et entre du texte dans le champ Description, l'interface utilisateur d'Orchestrator l'enregistre dans le champ Informations personnalisées (Custom Info), mais le champ Description est vide lorsque l'utilisateur examine ce dispositif Edge nouvellement provisionné.
  Problème résolu n° 123070	Dans une entreprise cliente avec une topologie Hub/Spoke, lors de la configuration d'une business policy dans laquelle l'option Backhaul Internet (Internet Backhaul) est sélectionnée, un utilisateur ne peut pas sélectionner les Hubs de backhaul (Backhaul Hubs). Le backhaul ne peut donc pas fonctionner pour cette règle.
  Problème résolu n° 127037	Lorsqu'un utilisateur accède à Surveiller (Monitor) > Dispositif Edge (Edge) > Sources, il ne peut pas modifier le nom d'hôte d'un client. Un utilisateur doit pouvoir modifier le nom d'hôte d'un client en cliquant sur l'icône Modifier (Edit) et en ouvrant la zone Modifier le nom d'hôte (Change Hostname). Bien que l'utilisateur puisse entrer du texte sous le champ Modifier le nom d'hôte (Change Hostname), s'il clique sur Enregistrer les modifications (Save Changes), le nouveau nom d'hôte n'est pas appliqué.
  Problème résolu n° 128628	Sur la page Gérer les clients (Manage Customers), l'option de téléchargement de l'exportation au format CSV ne fonctionne pas. Le seul moyen pour un client d'obtenir ces informations consiste à utiliser une API afin de télécharger les informations et de les convertir au format CSV.
  Problème résolu n° 128667	Le chargement de la page Gérer les clients (Manage Customers) ou Gérer les clients partenaires (Manage Partner Customers) peut prendre jusqu'à une minute lorsque le nombre de clients sur le dispositif Orchestrator ou le nombre de clients sous un partenaire est élevé.

• La build R5204-20230927-GA de l'interface utilisateur a été publiée le 28/09/2023 et constitue la 3e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 126967	Une fois OSPF activé sur un profil, les Paramètres OSPF avancés (OSPF Advanced Settings) de l'interface de routage Apprentissage de route entrante (Inbound Route Learning) et Annonce de route (Route Advertisement) ne sont pas accessibles et n'affichent aucun champ pour entrer les détails requis.
  Problème résolu n° 127006	Lorsqu'un utilisateur opérateur disposant du rôle Support accède à la page SD-WAN > Services réseau (Network Services) et clique sur une destination non-SD-WAN via une passerelle, il peut cliquer sur +NOUVEAU (+NEW) pour créer et configurer une NSD. Un opérateur avec un rôle Support doit disposer de privilèges en lecture seule sur la page Services réseau (Network Services) et ne pas être en mesure de créer une NSD via une passerelle.
  Problème résolu n° 127843	L'interface utilisateur ne s'affiche pas correctement lorsqu'elle est localisée en italien et entraîne le chevauchement de certains onglets de navigation.
  Problème résolu n° 127849	Le bouton Afficher le certificat (View Certificate) est grisé et il n'est pas possible de cliquer dessus sur l'écran Dispositif Edge (Edge) > Configuration > Présentation (Overview), ce qui empêche les utilisateurs d'afficher les certificats du dispositif Edge. Sans correctif pour l'interface utilisateur, un utilisateur peut afficher le certificat d'un dispositif Edge en accédant à la liste des dispositifs Edge sous l'onglet Configuration et en recherchant le dispositif Edge souhaité.
  Problème résolu n° 127871	La page Présentation du réseau (Network Overview) ne s'actualise pas automatiquement et n'offre pas non plus l'option d'activer l'actualisation automatique. Les utilisateurs doivent donc actualiser manuellement la page pour afficher les dernières données.
  Problème résolu n° 128277	Lorsqu'un utilisateur partenaire ou d'entreprise natif (qui se connecte à Orchestrator avec un nom d'utilisateur et un mot de passe) tente de se connecter avec un mot de passe ayant expiré, l'interface utilisateur entre dans une boucle et affiche un écran vide.

• La build R5204-20230920-GA de l'interface utilisateur a été publiée le 21/09/2023 et constitue la 2e build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 106191	Si une interface Edge est configurée avec des adresses IP statiques au niveau du profil, un utilisateur ne peut pas apporter de modifications supplémentaires au dispositif Edge.
  Problème résolu n° 113254	Les utilisateurs partenaires ne sont pas autorisés à modifier les images logicielles de leurs clients en raison de contraintes liées aux privilèges.
  Problème résolu n° 117941	La case Annonce VLAN (VLAN Advertise) est toujours décochée à l'écran. Même lorsque la case est cochée et que les modifications sont enregistrées, la case Annonce VLAN (VLAN Advertise) dans l'interface utilisateur d'Angular est à nouveau décochée.
  Problème résolu n° 117993	Lorsqu'un administrateur tente de réinitialiser le mot de passe d'un utilisateur d'entreprise ou partenaire, la demande échoue et une erreur indiquant « L'utilisateur ne dispose pas des privilèges requis pour accéder à (User does not have privileges required to access) » s'affiche.
  Problème résolu n° 121469	Sur la page Paramètres globaux (Global Settings) > Gestion des utilisateurs (User Management), un utilisateur observe toujours une bannière d'alerte de verrouillage sur la page Présentation de l'utilisateur (User Overview), même s'il est probablement déverrouillé et qu'il peut se connecter.
  Problème résolu n° 126503	Dans une entreprise utilisant une destination non-SD-WAN (NSD) via une passerelle d'un type quelconque, si un utilisateur modifie la valeur PSK d'une NSD et l'enregistre, l'interface utilisateur d'Orchestrator ignore la modification et revient à la valeur par défaut d'origine.
  Problème résolu n° 126257	La valeur située tout en haut de la page Surveiller (Monitor) > Dispositif Edge (Edge) > Liens (Links) n'est pas visible lorsque les valeurs extrêmement élevées sont nombreuses. Cela est dû au fait que la hauteur du graphique était précédemment calculée en additionnant des valeurs inférieures, ce qui se traduisait par un graphique imprécis et l'impossibilité de l'aligner avec l'échelle.

• La build R5204-20230914-GA de l'interface utilisateur a été publiée le 15/09/2023 et constitue la 1re build d'interface utilisateur ajoutée à la version 5.2.0.4 d'Orchestrator.

  Le tableau suivant répertorie tous les correctifs pour cette build d'interface utilisateur avec une description des symptômes de chaque problème.

  Ticket	Symptôme/Description
  Problème résolu n° 108125	Sur la page Surveiller (Monitor) > Dispositif Edge (Edge) > Application, lorsqu'un utilisateur clique sur un point du graphique pour obtenir plus de détails, puis clique une deuxième fois sur le graphique, la fenêtre de détails ne s'ouvre pas correctement et n'est pas fonctionnelle.
  Problème résolu n° 122918	Dans une entreprise utilisant une topologie Site distant vers Hubs (Branch to Hubs), lorsqu'un utilisateur accède à la section Configurer (Configure) > Périphérique (Device) > VPN cloud (Cloud VPN) de l'interface utilisateur et tente de modifier le paramètre Site distant vers le site du Hub (Branch to Hub Site) ou VPN site distant vers site distant (Branch to Branch VPN), l'utilisateur est bloqué et est informé que les Hubs sont en cours d'utilisation. Ce problème peut se produire si d'autres services sont utilisés dans une business policy et que l'interface utilisateur les prend en compte par erreur lors du calcul de l'utilisation du backhaul et bloque la modification.
  Problème résolu n° 123619	Si un dispositif Orchestrator n'a pas accès à Internet (par exemple, un dispositif sur site), la page Surveiller (Monitor) > Dispositif Edge (Edge) > Présentation (Overview) est vide.
  Problème résolu n° 123927	Lorsqu'OSPF est configuré pour un VLAN, un utilisateur peut désactiver le paramètre VLAN Interface passive (Passive Interface) pour un dispositif Edge, même si le mode OSPF passif est le seul pris en charge.
  Problème résolu n° 124801	Lorsqu'un utilisateur opérateur définit la propriété système « Session.options.enableEdgeLicensing » sur False, un utilisateur doit toujours créer un dispositif Edge en sélectionnant d'abord une licence Edge. La définition de cette propriété système sur False permet aux dispositifs Orchestrator contrôlés par les partenaires de contourner l'étape de sélection d'une licence Edge s'ils n'en ont pas besoin lors du processus de provisionnement de leur dispositif Edge. Cependant, en raison de ce problème, l'utilisateur doit toujours sélectionner une licence.
  Problème résolu n° 125309	Lorsqu'un utilisateur désactive IPv6 au niveau du dispositif Edge sous Configurer (Configure) > Périphérique (Device) > Paramètres IPv6 (IPv6 Settings), l'option OSPF pour IPv6 peut toujours être modifiée, activée et enregistrée.
  Problème résolu n° 125393	Dans le tableau Configurer (Configure) > Périphérique (Device) > VLAN au niveau du profil, la colonne OSPF est manquante.
  Problème résolu n° 125710	Dans une entreprise utilisant une topologie Site distant vers Hubs (Branch to Hubs), si un dispositif Edge utilisé dans un VPN cloud est supprimé de l'entreprise, l'utilisateur ne peut pas supprimer ultérieurement un dispositif Hub Edge utilisé dans un VPN site distant vers site distant (Branch to Branch VPN) et la modification des paramètres du périphérique est bloquée.
  Problème résolu n° 126403	L'interface utilisateur peut ne pas parvenir à charger la page Présentation du partenaire (Partner Overview) en raison d'un problème lié à la version 5.2.0.4 de l'image logicielle.
  Problème résolu n° 127007	Dans une entreprise utilisant une topologie Hub/Spoke, lorsqu'un utilisateur modifie un paramètre sur la page Configurer (Configure) > Périphérique (Device) d'un profil, l'ordre des Hubs est automatiquement remplacé par la valeur par défaut, ce qui affecte tous les dispositifs Edge utilisant ce profil.

• Problème résolu 65668 : Un client abonné au service Cloud Web Security ne peut pas vérifier quelles passerelles VMware SD-WAN Gateway sont attribuées pour gérer le trafic de Cloud Web Security lorsqu'il examine la page Attribution de passerelle (Gateway Assignment).

  Le client doit voir les attributions principale et secondaire pour les passerelles (également appelées PoP SASE) qui gèrent Cloud Web Security.

• Problème résolu 104775 : lorsqu'un utilisateur configure un lien WAN précédemment actif sur un dispositif VMware SD-WAN Edge comme sauvegarde, l'interface utilisateur de VMware SASE Orchestrator n'affiche pas correctement l'état dans Surveiller (Monitor) > Dispositifs Edge (Edges) > Présentation (Overview).

  L'état du lien de sauvegarde devrait indiquer Passif (Standby) et Inactif (Idle) avec un point d'état gris, mais il n'affiche ni le type de lien ni l'état de la sauvegarde. Il s'agit d'un défaut superficiel, car le lien WAN joue son rôle de sauvegarde.

• Problème résolu 118728 : dans un portail partenaire ou une entreprise cliente, certains utilisateurs peuvent ne pas être autorisés à se connecter à VMware SASE Orchestrator.

  L'utilisateur peut voir l'erreur « L'utilisateur ne dispose pas du privilège [READ:PROXY] requis pour accéder à [enterpriseProxy/getEnterpriseProxy] (User does not have privilege [READ:PROXY] required to access [enterpriseProxy/getEnterpriseProxy]) », même s'il dispose des privilèges appropriés pour se connecter. Cela s'applique à l'authentification native et à l'authentification à deux facteurs. Cette erreur provient en fait d'un mot de passe ayant expiré même si Orchestrator n'informe pas l'utilisateur de la véritable raison pour laquelle il ne peut pas se connecter. L'utilisateur est par ailleurs dans l'impossibilité de réinitialiser son mot de passe puisqu'il ne peut pas se connecter.

  Sur un dispositif Orchestrator sans correctif pour ce problème, un administrateur de partenaire ou de client disposant d'un rôle approprié peut envoyer un e-mail de réinitialisation de mot de passe à un utilisateur concerné pour lui permettre de réinitialiser son mot de passe.

• Problème résolu 120398 : un utilisateur partenaire ne peut pas créer de profil de configuration pour une entreprise cliente qu'il gère.

   Lorsque l'utilisateur partenaire tente de créer un profil de configuration pour son client, Orchestrator génère l'erreur « Contexte d'entreprise de proxy non valide pour le profil d'opérateur (Invalid proxy enterprise context for operator profile) ». Ce problème se produit pour tout rôle de partenaire disposant de privilèges de configuration.

  

• Problème résolu 121118 : un utilisateur d'entreprise ne peut ni générer un bundle de diagnostics ni générer et télécharger une capture de paquets sur VMware SASE Orchestrator.

  Cela concerne tous les rôles d'utilisateur d'entreprise (y compris le rôle de super utilisateur). Normalement, sous SD-WAN > Diagnostiques (Diagnostics), un utilisateur d'entreprise doit pouvoir :

  1. Générer (sans télécharger) un bundle de diagnostics.

  2. Générer et télécharger une capture de paquets.

  Toutefois, les seules options qui lui sont proposées sont Diagnostics à distance (Remote Diagnostics) et Actions à distance (Remote Actions).

  

  Si vous rencontrez ce problème sur une build d'Orchestrator sans correctif pour ce problème, contactez le support SD-WAN qui pourra vous venir en aide et générer le bundle de diagnostics pour vous.

• Problème résolu 121526 : un utilisateur disposant d'un rôle Entreprise en lecture seule (Enterprise Read Only) n'est pas autorisé à afficher les graphiques Surveiller (Monitor) > Dispositifs Edge (Edges) > QoE dans l'interface utilisateur de VMware SASE Orchestrator.

  Une tentative d'affichage du graphique QoE génère une bannière d'erreur indiquant « L'utilisateur ne dispose pas du privilège [READ:ENTERPRISE_EVENT] requis pour accéder à [event/getEnterpriseEventsList] (User does not have privilege [READ:ENTERPRISE_EVENT] required to access [event/getEnterpriseEventsList]) ».

  

• Problème résolu 122113 : un utilisateur ne peut pas rechercher l'événement « DNS_CACHE_LIMIT_REACHED » sur la page Événements (Events) de l'interface utilisateur de VMware SASE Orchestrator.

  Cet événement est publié lorsqu'il est déclenché sur la page Surveiller (Monitor) > Événements (Events) pour une entreprise cliente, mais il n'est pas répertorié comme valeur pouvant faire l'objet d'une recherche lors d'une tentative d'utilisation de la fonction de recherche. Par conséquent, l'utilisateur ne peut pas voir combien de fois cet événement a été publié sur une période donnée.

• Problème résolu 123002 : la mise à niveau d'un dispositif VMware SD-WAN Edge peut échouer, car le logiciel n'est que partiellement téléchargé avant la fermeture prématurée de la connexion.

  Le problème est dû au fait que la valeur du délai d'expiration du téléchargement dans VMware SASE Orchestrator est incorrectement définie, ce qui entraîne la fermeture de certaines sessions de téléchargement avant qu'elles n'aboutissent. Le correctif restaure la valeur correcte du délai d'expiration afin que le téléchargement puisse aller jusqu'au bout.

• Problème résolu 123053 : lorsqu'un utilisateur configure un nom SNMP v3, l'interface utilisateur de VMware SASE Orchestrator rejette tout nom comprenant un caractère non alphanumérique et génère une erreur.

  Dans Configurer (Configure) > Périphérique (Device) > Télémétrie (Telemetry) > SNMP pour les noms SNMP version 3, Orchestrator rejette les caractères non alphanumériques tels que [@\'"/,#%&*(){}_=`:?[]§;|><]. Un nom tel que User_23 n'est donc pas accepté et entraîne le message d'erreur « Caractères non autorisés dans ce champ (Characters not allowed in this field) », ce qui limite le choix d'un nom SNMP v3 pour un utilisateur.

  

• Problème résolu 123150 : Pour le site d'une entreprise cliente utilisant une topologie haute disponibilité, lorsque le client configure une VNF, puis active l'insertion de la VNF, VMware SASE Orchestrator n'indique pas que l'insertion de la VNF a réussi et l'état de la VNF ne s'affiche pas sur le dispositif Edge HA.

  Ce problème est dû au fait qu'Orchestrator envoie à tort un paramètre VNF pour l'insertion d'interface avec la valeur False, même s'il existe des interfaces avec l'insertion de la VNF activée dans Configurer (Configure) > Dispositif Edge (Edge) > Paramètres de l'interface (Interface Settings). Étant donné que ce champ est envoyé avec la valeur False dans la configuration d'Orchestrator, le dispositif Edge HA n'active l'insertion de la VNF sur aucune interface.

  Sur un dispositif Orchestrator sans correctif pour ce problème, vous devez désactiver HA pour ce site, transformer le dispositif Edge HA en dispositif Edge autonome, reconfigurer chaque VNF, puis activer l'insertion de la VNF. Une fois la configuration réussie, vous pouvez réactiver HA pour le site.

• Problème résolu 123346 : les entreprises clientes existantes ne peuvent pas activer la fonctionnalité Journalisation du pare-feu dans Orchestrator (Firewall Logging to Orchestrator) sur la version 5.2.0 de VMware SASE Orchestrator.

  Bien que la fonctionnalité Journalisation du pare-feu Edge hébergée par VMware (VMware Hosted Edge Firewall Logging) ait été ajoutée dans la version 5.2.0, les clients créés avant la mise à niveau de leur dispositif Orchestrator vers la version 5.2.0 ne voyaient pas l'option permettant d'activer cette fonctionnalité après la mise à niveau.

• Problème résolu 123551 : lors de la création ou de la modification d'un mot de passe pour l'interface Wi-Fi d'un dispositif VMware SD-WAN Edge, l'utilisateur constate que l'interface utilisateur d'Orchestrator nécessite un mot de passe de 10 caractères, alors qu'il ne devrait en comporter que 8.

  L'obligation d'utiliser 10 caractères a été créée par inadvertance dans la version 5.1.0 d'Orchestrator à la suite d'une classification incorrecte du processus Wi-Fi. La longueur de 8 caractères a été rétablie dans cette build.

• Problème résolu 123749 : un administrateur d'entreprise (Enterprise Administrator) ou un utilisateur Support de l'entreprise (Enterprise Support) ne peut pas afficher l'option Bundles de diagnostics (Diagnostic Bundles) sur l'écran Diagnostics de l'interface utilisateur de VMware SASE Orchestrator, alors que son rôle est personnalisé pour faire cela.

  Par défaut, ces deux rôles ne peuvent pas voir l'option Diagnostics > Bundles de diagnostics (Diagnostic Bundles) dans l'interface utilisateur, mais il est possible de les personnaliser afin d'ajouter des privilèges pour les bundles de diagnostics et les PCAP, ce qui devrait ajouter l'écran Bundles de diagnostics (Diagnostic Bundles).

• Problème résolu 124073 : si un utilisateur configure une destination non-SD-WAN via une passerelle à l'aide de tunnels de passerelle redondants avec le chiffrement AES-256, le tunnel de passerelle redondant en veille continue d'utiliser le chiffrement AES-128.

  Un utilisateur accède à Configure (Configure) > Services réseau (Network Services) sur l'interface utilisateur d'Orchestrator et remplace l'algorithme de chiffrement par AES-256 pour une NSD avec des tunnels redondants. Dans la réponse de l'API, l'utilisateur constate que le tunnel redondant continue d'utiliser AES-128, ce qui est dû à un défaut de l'API qui gère le changement de chiffrement du tunnel.

• Problème résolu 124129 : si la propriété système qui contrôle la disponibilité du service de pare-feu amélioré (EFS, Enhanced Firewall Service) est définie sur True, EFS est activé par défaut pour toute nouvelle entreprise cliente ajoutée à VMware SASE Orchestrator.

  Par défaut, la propriété système enterprise.capability.enableATP est définie sur True sur les builds 5.2.0 précédentes. Lorsque cette propriété est définie sur True, un utilisateur observe qu'EFS est activé par défaut dans les Paramètres globaux (Global Settings) du client pour une nouvelle entreprise cliente. Le comportement attendu est le suivant : EFS ne doit pas être activé par défaut pour chaque nouvelle entreprise cliente et cette fonctionnalité doit être activée explicitement.

  Ce problème est corrigé dans la build 5.2.0.4 dans laquelle la propriété enterprise.capability.enableATP est définie sur False par défaut.

• Problème résolu 124273 : un utilisateur opérateur peut constater que sa tentative de mise à niveau de VMware SASE Orchestrator vers une build 5.1.x ou 5.2.x échoue.

  Lorsque vous rencontrez ce problème, les journaux sont semblables aux suivants :

  • fatal: [vcoxxx]: FAILED! => changed=true
  • …
  • UPGRADE - DEBUG - Starting VCO software update preinstall
  • UPGRADE - WARNING - E: Unable to locate package linux-image-unsigned-x.x.x
  • UPGRADE - WARNING - E: Couldn't find any package by glob 'linux-image-unsigned-x.x.x-xxx'
  • UPGRADE - WARNING - E: Couldn't find any package by regex 'linux-image-unsigned-x.x.x-xxx'
  • UPGRADE - WARNING - E: No packages found
  • UPGRADE - ERROR - installer failed with return code 100. See /var/log/vco_software_update.log for details
  • UPGRADE - WARNING - Verification key does not exist: xxx

• Problème résolu 124315 : un utilisateur semble être en mesure de modifier un filtre BGP au niveau du dispositif Edge qui a été créé au niveau du profil à l'aide de l'interface utilisateur d'Orchestrator.

  Bien qu'un utilisateur puisse toujours remplacer les paramètres du profil sur un dispositif Edge à l'aide de l'option Remplacement du dispositif Edge (Edge Override), il ne doit jamais être en mesure de modifier les paramètres réels du profil. Dans ce cas, l'interface utilisateur donne à l'utilisateur l'impression qu'il peut modifier un filtre BGP transféré à partir d'un profil. Il s'agit d'un défaut superficiel, car aucune des opérations effectuées par l'utilisateur sur le filtre BGP du profil n'est appliquée à ce dispositif Edge ou à tout autre dispositif Edge.

• Problème résolu 124778 : lorsqu'un client accède à Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration), il ne voit pas l'option permettant de configurer sa stratégie de sécurité.

  La section Stratégies de sécurité (Security Policy) permet à un client de configurer sa Proposition d'IPsec Edge (Edge IPsec Proposal), notamment le chiffrement, le groupe DH, etc. Cette option est présente dans l'interface utilisateur classique, mais elle ne figure pas dans la nouvelle interface utilisateur qui est l'interface par défaut d'Orchestrator 5.2.0 et versions ultérieures.

• Problème résolu 124798 : un utilisateur ne peut pas modifier le numéro de série d'un dispositif VMware SD-WAN Edge sur l'interface utilisateur de VMware SASE Orchestrator.

  Pour un dispositif Edge provisionné ou traité par RMA, mais qui n'est pas encore activé, sur l'écran SD-WAN > Configurer (Configure ) > Dispositif Edge (Edge) > Présentation (Overview), sous État du dispositif Edge (Edge Status), le Numéro de série (Serial Number) du dispositif Edge est présent, mais le texte est en lecture seule et n'est pas modifiable. Cela pose problème, car certains clients peuvent ne pas connaître le numéro de série du dispositif Edge à activer avant sa livraison sur site et doivent pouvoir modifier ce champ pour qu'il corresponde au dispositif Edge livré.

• Problème résolu 125456 : pour une entreprise cliente dans laquelle des VNF sont utilisées, lorsqu'un utilisateur tente de modifier la configuration d'un dispositif Edge, VMware SASE Orchestrator rejette les modifications lorsqu'il tente de les enregistrer.

  Même si la modification apportée à la configuration est mineure, comme l'ajout d'un commentaire à une route statique existante, l'interface utilisateur d'Orchestrator n'enregistre pas la modification lorsqu'une VNF est activée. L'utilisateur peut observer une bannière Erreur d'injection de script (Script Injection Error) en bas de l'écran de l'interface utilisateur.

  La solution sur un dispositif Orchestrator sans correctif pour ce problème consiste à désactiver temporairement les VNF, puis à enregistrer les modifications de configuration. Une fois celles-ci enregistrées, l'utilisateur peut réactiver les VNF.

Résolu dans la version R5203-20230809-GA d'Orchestrator

La build R5203-20230809-GA d'Orchestrator a été publiée le 09/08/2023 et constitue la 3e build cumulative d'Orchestrator pour la version 5.2.0.

Cette build cumulative d'Orchestrator résout les problèmes critiques ci-dessous depuis la 2e build cumulative R5202-20230729-GA d'Orchestrator.

• Problème résolu 121118 : un utilisateur d'entreprise ne peut ni générer un bundle de diagnostics ni générer et télécharger une capture de paquets sur VMware SASE Orchestrator.

  Cela concerne tous les rôles d'utilisateur d'entreprise (y compris le rôle de super utilisateur). Normalement, sous SD-WAN > Diagnostiques (Diagnostics), un utilisateur d'entreprise doit pouvoir :

  1. Générer (sans télécharger) un bundle de diagnostics.

  2. Générer et télécharger une capture de paquets.

  Toutefois, les seules options qui lui sont proposées sont Diagnostics à distance (Remote Diagnostics) et Actions à distance (Remote Actions).

  

• Problème résolu 121884 : VMware SASE Orchestrator peut continuer à traiter et à stocker des fichiers journaux de pare-feu, même si la propriété système de cette action est définie sur false.

  Lorsque la propriété système storage.firewall.logs.file.enable est définie sur false, Orchestrator devrait arrêter le traitement et le stockage des fichiers journaux du pare-feu au niveau global, et aucune entreprise cliente ne devrait être en mesure d'obtenir de nouveaux journaux de pare-feu, quels que soient ses propres paramètres au niveau de l'entreprise. Cette propriété est utilisée comme outil de dépannage des problèmes de performances d'Orchestrator qui sont éventuellement liés au traitement des journaux de pare-feu. Dans les versions 5.2.0.1 et 5.2.0.2 d'Orchestrator, ce paramètre n'est pas respecté.

• Problème résolu 122132 : un client utilisant le service de pare-feu amélioré peut ne pas être en mesure de télécharger les définitions mises à jour pour les fonctionnalités Système de détection des intrusions (IDS, Intrusion Detection System) et Système de prévention des intrusions (IPS, Intrusion Prevention System).

  Le problème vient du fait que les profils d'opérateur de la version 5.2.0 n'incluent pas le module atpMetadata. Les dispositifs Edge utilisant un profil d'opérateur 5.2.0 ne peuvent pas télécharger les bundles de signatures IDPS pour appliquer IDS/IPS et n'obtiennent donc pas le niveau de protection attendu du service de pare-feu amélioré.

• Problème résolu 122797 : un utilisateur ne peut pas activer le paramètre « Activer le VPN site distant vers site distant » (Enable Branch to Branch VPN) sur un profil utilisé par un dispositif Hub Edge.

  Sur l'écran Configurer (Configure) > Profil (Profile) > Périphérique (Device) > Services VPN (VPN Services), l'interface utilisateur d'Orchestrator permet à l'utilisateur de cocher la case Activer le VPN site distant vers site distant (Enable Branch to Branch VPN), mais lorsqu'il tente d'enregistrer la configuration, l'interface utilisateur d'Orchestrator génère l'erreur « Impossible d'enregistrer les modifications. Votre configuration comporte une ou plusieurs erreurs. » (Cannot save changes. There is one or more errors within your configuration.). Cette erreur n'indique pas à l'utilisateur quelle est l'erreur réelle. Ce problème se produit uniquement sur la nouvelle interface utilisateur, qui est celle par défaut de la version 5.2.x.

• Problème résolu 123384 : lorsque l'utilisateur accède à la page SD-WAN > Configurer (Configure) > Dispositifs Edge (Edges) ou SD-WAN > Surveiller (Monitor) > Dispositifs Edge (Edges) sur VMware SASE Orchestrator et ajoute un filtre pour trier les éléments selon le profil d'opérateur, le profil de configuration ou l'analyse, la page ne renvoie aucun résultat et génère une erreur.

  L'utilisateur observe alors une page indiquant Échec du chargement des données (Failed to Load Data) et, s'il ouvre la console du navigateur, une entrée « Erreur d'API » (API Error).

  

• Problème résolu 123609 : un utilisateur ne peut pas enregistrer les modifications apportées à la liste de filtres BGP si le nombre de règles de filtre BGP dépasse dix.

   L'utilisateur ajoute des filtres BGP sur la page SD-WAN > Configurer (Configure) > Profil/Dispositif Edge (Profile/Edges) > Périphérique (Device) > Routage et NAT (Routing & NAT) > BGP d'Orchestrator. Si l'utilisateur ajoute de nouvelles règles de filtre à la Liste de filtres (Filter List) et que le nombre total de règles dépasse dix, l'enregistrement de cette configuration échoue et l'interface utilisateur d'Orchestrator affiche le message d'erreur « Impossible d'enregistrer les modifications. Votre configuration comporte une ou plusieurs erreurs. » (Cannot save changes. There is one or more errors within your configuration.).

  Ce problème est dû au fait que la nouvelle interface utilisateur (qui est celle par défaut de la version 5.2.x) utilise une indexation incorrecte dans le tableau des règles de filtre BGP, ce qui l'amène à démarrer à partir de la deuxième page de la pagination (11 règles et plus).

Résolu dans la version R5202-20230729-GA d'Orchestrator

La build R5202-20230729-GA d'Orchestrator a été publiée le 02/08/2023 et constitue la 2e build cumulative d'Orchestrator pour la version 5.2.0.

Cette build cumulative d'Orchestrator résout les problèmes critiques ci-dessous depuis la 1re build cumulative R5201-20230623-GA d'Orchestrator.

• Problème résolu 116666 : un partenaire disposant d'un rôle de super utilisateur ne peut pas activer le service de pare-feu amélioré pour l'une de ses entreprises clientes prises en charge.

  Cette option doit être disponible pour un super utilisateur partenaire lorsqu'il accède à Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration) sur VMware SASE Orchestrator.

• Problème résolu 117772 : Lorsque vous examinez l'écran Surveiller (Monitor) > Présentation du réseau (Network Overview) pour VMware SASE Orchestrator pour un client d'entreprise, les liens WAN dont l'état est Dégradé (Degraded) ou Inactif (Down) peuvent ne pas être inclus dans l'écran État du lien (Link status) si plus de 10 liens WAN sont surveillés.

  Ce problème est exclusif à la nouvelle interface utilisateur d'Orchestrator en raison d'un problème frontal qui ne prend pas en compte les liens WAN dans un état Dégradé (Degraded) ou Inactif (Down). La surveillance fonctionne comme prévu dans l'interface utilisateur classique.

• Problème résolu 117822 : lorsqu'un client examine Surveiller (Monitor) > Dispositifs Edge (Edges) > QoE, il peut observer des écarts dans les graphiques QoE qui ne s'expliquent pas par des problèmes avec les liens WAN du dispositif Edge.

  Les écarts sont le résultat d'un problème avec la base de données Orchestrator : la file d'attente des tâches internes pour les données de lien est manquée, et les données de lien ne sont pas renvoyées.

• Problème résolu 118544 : Un utilisateur peut observer qu'un profil d'opérateur ne se charge pas et qu'il est inaccessible, empêchant l'attribution de ce profil à une entreprise cliente.

  Un problème se produit avec la base de données Orchestrator : le profil d'opérateur est présent, mais un ID logique incorrect est ajouté à un module de configuration si une entreprise cliente est supprimée, ce qui empêche le chargement du profil.

• Problème résolu 118733 : Lorsqu'un utilisateur a recours à la nouvelle interface utilisateur de VMware SASE Orchestrator et configure une business policy ou une règle de pare-feu au niveau du profil qui est ensuite remplacée au niveau du dispositif Edge, les icônes du dispositif Edge remplacé ne sont pas correctement représentées pour Périphérique (Device), Activité (Business) et Pare-feu (Firewall) lorsque l'utilisateur examine l'écran Configurer (Configure)> Dispositifs Edge (Edges) > Répertorier les dispositifs Edge (List Edges).

  Lors de l'utilisation de la nouvelle interface utilisateur, qui est celle par défaut pour la version 5.2.0, les icônes pour lesquelles l'option Remplacement du dispositif Edge (Edge Override) est cochée sont vides au lieu d'être de couleur unie. L'interface utilisateur classique d'Orchestrator affiche correctement des icônes de couleur unie lorsqu'un remplacement du dispositif Edge est configuré pour une catégorie particulière.

  

• Problème résolu 120070 : pour un client qui déploie un service de sécurité cloud (CSS) de type Zscaler avec l'option « Automatiser le déploiement du service cloud » (Automate Cloud Service Deployment) activée, si un utilisateur accède à Surveiller (Monitor) > Services réseau (Network Services) > Services de sécurité cloud (Cloud Security Services) > État du déploiement (Deployment Status), aucune option ne lui permet d'afficher l'état de ce CSS.

  Cet écran de surveillance et État du déploiement (Deployment Status) en particulier sont importants pour tout client déployant un CSS Zscaler automatisé.

• Problème résolu 120606 : Lorsqu'un utilisateur tente de créer un rôle sur Client (Customer) > Paramètres globaux (Global Settings) > Gestion des utilisateurs (User Management) > Nouveau rôle (New Role), il observe une erreur et les privilèges ne sont pas chargés.

  Lorsque ce problème se produit, l'utilisateur voit une « erreur de méthode » sur la page de l'interface utilisateur lors de la création d'un rôle, ce qui empêche également le chargement des privilèges.

  

• Problème résolu 120774 : pour un client déployant des destinations non-SD-WAN via une passerelle (NSD), lorsqu'un utilisateur accède à Surveiller (Monitor) > Services réseau (Network Services) ou à Configurer (Configure) > Services réseau (Network Services) et clique sur une NSD, il peut ne pas voir les paramètres IKE d'un tunnel NSD.

  Un utilisateur observe l'erreur suivante : Impossible de lire les propriétés d'une valeur non définie (lecture de « clearDontFragmentBit ») [Cannot read Properties of undefined (reading 'clearDontFragmentBit')] et rien ne s'affiche.

• Problème résolu 121441 : Lorsqu'un client active l'insertion de la VNF sur le VLAN d'un dispositif VMware SD-WAN Edge, le dispositif Edge supprime, puis redéploie la VNF, ce qui la rend inutilisable pour ce dispositif Edge.

  Une fois l'insertion de la VNF activée sur le VLAN, le client observe des événements de suppression et de redéploiement de la VNF sur la page Surveiller (Monitor) > Événements (Events) et reçoit un e-mail avec le message « (VNF_VM_DELETED) / Fournisseur inconnu La VNF a été supprimée sur le dispositif Edge <Nom du dispositif Edge> (Unknown vendor VNF was deleted on the edge <Edge Name>) ». Le problème vient du fait que l'instance d'Orchestrator envoie un nouvel UUID (Universally Unique IDentifier) après l'activation de l'insertion de la VNF sur un VLAN. Le dispositif Edge interprète cette modification de l'UUID comme un déclencheur pour supprimer la VNF et la redéployer, ce qui la rend inutilisable pour ce dispositif Edge.

  Ce problème se produit uniquement sur la nouvelle interface utilisateur, qui est celle par défaut d'Orchestrator 5.2.0. Par conséquent, il n'existe aucune solution lors de l'utilisation de cette version en l'absence de correctif.

• Problème résolu 121472 : lorsque l'authentification à deux facteurs (2FA) est activée pour une entreprise cliente, un compte d'utilisateur individuel ne peut pas désactiver 2FA pour lui-même.

  Si 2FA est activée pour un client, une case à cocher doit permettre de la désactiver ou de l'exiger lorsque vous cliquez sur les détails du compte d'un utilisateur. Le correctif ajoute une option bascule pour 2FA qui indique clairement l'état de 2FA pour cet utilisateur.

• Problème résolu 121751 : un utilisateur opérateur ou partenaire n'est pas autorisé à réattribuer la passerelle VMware SD-WAN Gateway utilisée par une destination non-SD-WAN (NSD) via une passerelle à une autre passerelle lors de l'utilisation de l'interface utilisateur de VMware SASE Orchestrator.

  Lorsqu'un super utilisateur opérateur ou partenaire accède à Passerelles (Gateways) > Gestion des passerelles (Gateway Management), il ne peut pas réattribuer la passerelle qu'une NSD utilise via une passerelle à une autre passerelle, ces passerelles étant configurées pour avoir un rôle Passerelle VPN sécurisée (Secure VPN Gateway). L'utilisateur peut cliquer sur une autre passerelle, mais l'interface utilisateur d'Orchestrator ne lui permet pas de cliquer ensuite sur le bouton Attribuer une passerelle (Assign Gateway) pour terminer la réattribution.

• Problème résolu 121835 : lorsqu'un utilisateur tente d'activer la fonctionnalité Annoncer (Advertise) sur une interface Loopback, la zone contextuelle Enregistrer (Save) ne s'affiche pas, et l'utilisateur n'a pas la possibilité d'enregistrer les données de configuration des Paramètres du périphérique Edge (Edge Device Settings).

  Lorsqu'un utilisateur tente de Modifier (Edit) une interface Loopback dans Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device), la boîte de dialogue Modifier (Edit) ne se charge pas correctement. Cela est dû au fait que l'interface utilisateur attend des paramètres OSPF dans un segment autre que le segment global alors que la configuration OSPF n'est autorisée que sur le segment global. Ce problème se produit uniquement dans les entreprises sur des instances de SASE Orchestrator mises à niveau vers la version 5.2.0 à partir d'une version précédente et uniquement si l'entreprise contient des interfaces Loopback sur plusieurs segments.

  Si l'entreprise cliente utilise une instance d'Orchestrator sans correctif pour ce problème, la seule solution consiste à modifier les paramètres du périphérique à l'aide d'appels d'API.

• Problème résolu 121858 : pour une instance de VMware SASE Orchestrator déployée dans une topologie de récupération d'urgence (DR), lorsque l'instance d'Orchestrator est mise à niveau vers la build cumulative 5.2.0.1, la synchronisation DR peut échouer, entraînant des écarts de données importants après un basculement d'Orchestrator.

  Dans le cadre de la mise à niveau logicielle d'Orchestrator, le système de gestion de base de données (DBMS, Database Management System) ClickHouse est mis à niveau de la version 20.3.19.4 vers la version 22.3.13.80. Pendant la mise à niveau, le processus DBMS supprime toutes les autorisations de groupe et restreint l'accès au répertoire de données au DBMS. Ce comportement interrompt le processus de réplication basé sur rsync et entraîne l'échec de la synchronisation des données DBMS entre les dispositifs Orchestrator actif et en veille.

  Si un opérateur utilise la build 5.2.0.1 d'Orchestrator, il peut corriger le problème d'autorisation sur l'instance d'Orchestrator active à l'aide de la commande suivante : chmod g+rx /store3/clickhouse.

• Problème résolu 121993 : un utilisateur peut ne pas avoir la possibilité de modifier les propriétés VLAN d'un dispositif VMware SD-WAN Edge sur l'interface utilisateur de VMware SASE Orchestrator.

  Lorsque le problème se produit, bien qu'il n'affecte pas tous les VLAN utilisés par un dispositif Edge, rien ne se passe lorsque l'utilisateur clique sur un VLAN dans l'interface utilisateur.

  Si un client rencontre ce problème sur une instance d'Orchestrator sans correctif pour ce problème, contactez le support SD-WAN pour obtenir de l'aide.

• Problème résolu 122010 : lorsqu'un opérateur accède aux propriétés système sur une instance de VMware SASE Orchestrator exécutant la build 5.2.0.1 d'Orchestrator et tente d'effectuer une recherche, la page peut ne pas se charger.

  Ce problème se déclenche si une ou plusieurs Propriétés système (System Properties) ont une valeur null (c'est-à-dire une valeur non définie).

• Problème résolu 122271 : Lorsqu'un client ajoute des règles NAT côté LAN supplémentaires à un profil à l'aide de la nouvelle interface utilisateur de VMware SASE Orchestrator, il peut observer que tout le trafic correspondant à ces règles échoue pour les dispositifs Edge utilisant ce profil.

  La nouvelle interface utilisateur calcule de manière incorrecte le masque externe NAT côté LAN à partir du préfixe d'adresse interne. Lorsque les règles ne sont pas écrites de sorte que le préfixe interne et le préfixe externe sont identiques (en d'autres termes, 1:1), le comportement des règles change et peut devenir non fonctionnel si un utilisateur modifie une règle NAT côté LAN à partir de la nouvelle interface utilisateur. Étant donné que la nouvelle interface utilisateur est l'interface utilisateur par défaut de la version 5.2.0 d'Orchestrator, ce problème n'a aucune solution.

• Problème résolu 122520 : sur une entreprise cliente qui utilise OSPF pour le routage ainsi que des interfaces Loopback, dans certains cas, l'interface Loopback peut ne pas s'ouvrir du tout.

  Ce problème vient du fait que VMware SASE Orchestrator ne charge pas OSPF sur l'interface Loopback lorsqu'OSPF est configuré sur l'une d'elles.

• Problème résolu 122866 : lorsqu'un utilisateur supprime un transfert BGP d'une passerelle partenaire, VMware SASE Orchestrator supprime également ce transfert BGP de toutes les autres passerelles partenaires du même pool de passerelles.

  Ce problème se produit que l'utilisateur soit un opérateur ou un partenaire, mais uniquement sur la nouvelle interface utilisateur qui est celle par défaut pour la version 5.2.0 d'Orchestrator.

  La solution consiste à isoler la passerelle partenaire dont le transfert BGP doit être supprimé en la supprimant temporairement du pool de passerelles. De cette façon, les autres passerelles partenaires ne sont pas affectées. Une fois le transfert BGP supprimé, l'utilisateur peut restaurer cette passerelle partenaire dans le pool de passerelles d'origine.

• Problème résolu 122977 : un utilisateur peut ne pas disposer de l'option lui permettant d'activer les services de pare-feu améliorés sur l'interface utilisateur de VMware SASE Orchestrator.

  Cette option doit s’afficher à trois endroits :

  • Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration) > Paramètres de SD-WAN (SD-WAN Settings) > Accès à la fonctionnalité (Feature Access), directement sous l'option Pare-feu avec état (Stateful Firewall).

  • Configurer (Configure) > Profil (Profile) > Pare-feu (Firewall), en tant qu'option une fois l'État du pare-feu (Firewall Status) défini sur Activé (On).

  • Configurer (Configure) > Dispositif Edge (Edge) > Pare-feu (Firewall), en tant qu'option une fois l'État du pare-feu (Firewall Status) défini sur Activé (On).

  Dans tous les cas, l'option est manquante.

  Ce problème est dû au fait qu'Orchestrator pense à tort que l'entreprise cliente n'est pas compatible avec la fonctionnalité Services de pare-feu améliorés (Enhanced Firewall Services).

Résolu dans Orchestrator version R5201-20230623-GA

La build R5201-20230623-GA d'Orchestrator a été publiée le 26/06/2023 et constitue la 1re build cumulative d'Orchestrator pour la version 5.2.0.

Cette build cumulative d'Orchestrator résout les problèmes critiques ci-dessous depuis la build GA R5200-20230529-GA initiale.

Important:

Il est fortement recommandé aux clients qui utilisent une instance d'Orchestrator sur site avec la build 5.2.0.0 d'effectuer la mise à niveau vers la version 5.2.0.1.

• Problème résolu 112333 : un dispositif VMware SASE Orchestrator gérant environ 4 000 dispositifs VMware SD-WAN Edge avec environ 6 000 tunnels et un flux de trafic continu peut devenir instable sur une période d'environ 4 jours et commencer à déconnecter les utilisateurs de manière aléatoire.

  Cette contrainte entraîne une défaillance de la base de données de l'Orchestrator et déclenche l'erreur « connect ECONNREFUSED » suivie de l'adresse IP de l'Orchestrator. Ce problème n'a été observé que dans un environnement de test à grande échelle et non dans un déploiement sur le terrain.

• Problème résolu 113254 : Un administrateur partenaire disposant du rôle Super utilisateur ou Standard ne peut pas modifier le profil d'opérateur par défaut d'un client sous sa gestion.

  Le même administrateur partenaire observe qu'il peut effectuer cette action lors de l'utilisation de l'interface utilisateur classique qui n'est pas disponible dans la version 5.2.0.

• Problème résolu 115411 : Pour VMware SASE Orchestrator utilisant la version 5.1.0 ou une version ultérieure et déployé avec une topologie de récupération d'urgence, la synchronisation peut échouer en raison d'un problème de base de données.

  Le processus spécifique qui échoue est dr_utils.js, car il est obsolète sur la dernière version du logiciel de base de données d'Orchestrator disponible dans les versions 5.1.0 et ultérieures.

• Problème résolu 115624 : Une instance de VMware SASE Orchestrator peut connaître une utilisation élevée du CPU et une instabilité, ainsi qu'un ralentissement observé dans le chargement des pages de l'interface utilisateur Paramètres du périphérique (Device Settings) et Paramètres réseau (Network Settings) lorsque le service du portail est redémarré.

  Ce problème est observé sur une instance d'Orchestrator avec environ 2 000 dispositifs Edge connectés lors de l'utilisation simultanée des services de sécurité cloud (CSS) et peut se produire avec ce nombre de dispositifs Edge connectés ou plus. Il est dû au fait que plusieurs processus Orchestrator liés aux configurations du dispositif Edge, du profil et du réseau sont chargés depuis les dispositifs Edge vers Orchestrator et prennent beaucoup plus de temps que prévu (environ 60 secondes ou plus).

• Problème résolu 116141 : Lorsqu'un utilisateur modifie les paramètres du périphérique sur un profil de configuration, VMware SASE Orchestrator peut prendre jusqu'à une minute pour valider les modifications.

  Chaque modification peut prendre jusqu'à une minute pour être validée et appliquée, alors que cela ne devrait prendre que quelques secondes. Le problème provient d'un processus de l'Orchestrator qui non seulement récupère la totalité des enregistrements de configuration du dispositif Edge associé à ce profil, mais qui décode et analyse chaque enregistrement, ce qui est à la fois inutile et coûteux pour le CPU de l'Orchestrator. Le correctif garantit que le processus récupère uniquement un nombre d'enregistrements.

• Problème résolu 116790 : lorsqu'un dispositif VMware SASE Orchestrator est mis à niveau vers la version 5.1.x ou une version ultérieure, les dispositifs VMware SD-WAN Edge client peuvent être rétrogradés par inadvertance vers une version antérieure à celle pour laquelle le dispositif Edge est configuré.

   Ce problème se produit lorsqu'une entreprise cliente est supprimée d'Orchestrator et que l'entreprise supprimée était associée à un profil d'opérateur par son ID logique dans la base de données d'Orchestrator. Lorsque l'entreprise est supprimée, le profil d'opérateur est également supprimé. Les clients dont la Gestion des images Edge (Edge Image Management) est configurée et qui disposent de plusieurs profils d'opérateur et auxquels ce profil d'opérateur supprimé a été attribué par défaut, se voient alors attribuer un profil d'opérateur qui reste disponible dans leur menu Gestion des images Edge (Edge Image Management).

  Par conséquent, un profil d'opérateur contenant une version d'Edge beaucoup plus ancienne peut être attribué au client, et le logiciel des dispositifs Edge auxquels ce profil d'opérateur est attribué peut être modifié et éventuellement rétrogradé si la version logicielle du dispositif Edge est remplacée par une version nettement inférieure. Cela peut avoir des effets perturbateurs qui peuvent notamment prendre la forme d'une panne réseau si le dispositif Edge exécute une version antérieure ne prenant pas en charge les fonctionnalités utilisées par le client.

• Problème résolu 117527 : L'utilisateur configure BGP au niveau du profil. Le navigateur peut cesser de répondre si un nombre important de règles sont configurées.

  Ce problème n'est pas observé sur l'interface utilisateur classique, qui n'est pas disponible sur la version 5.2.0 d'Orchestrator.

• Problème résolu 117800 : lorsqu'un dispositif VMware SASE Orchestrator est mis à niveau de la version 4.x vers la version 5.1.x ou ultérieure, l'opérateur peut constater qu'après le redémarrage du processus backend, le même fichier upgradeSchema.sql est créé, même s'il a été exécuté avec succès.

  Ce problème survient pendant la mise à jour du schéma, après la mise à niveau, et une fois le script post-schéma exécuté. Le fichier upgradeSchema.sql ne doit pas être généré à nouveau.

• Problème résolu 117993 : Lorsqu'un utilisateur partenaire gérant des entreprises clientes qui utilisent l'authentification native (c'est-à-dire un nom d'utilisateur et un mot de passe) ou qu'un utilisateur d'entreprise tente de réinitialiser un mot de passe pour un utilisateur d'entreprise, la tentative échoue.

  L'utilisateur observe l'erreur suivante : l'utilisateur ne dispose pas des privilèges requis pour accéder à [enterpriseUser/sendEnterpriseUserPasswordResetEMail] (user does not have privileges required to access [enterpriseUser/sendEnterpriseUserPasswordResetEMail]). Ce problème se produit uniquement sur la nouvelle interface utilisateur, qui est l'interface utilisateur par défaut de la version 5.2.0, et est dû à des paramètres de demande manquants.

• Problème résolu 118071 : la tentative de l'utilisateur de modifier les paramètres VPN dans Configurer (Configure) > Profil (Profile) > Périphérique (Device) peut échouer avec une erreur s'il y a plusieurs passerelles VMware SD-WAN Gateway attribuées au client, qui ont toutes environ 2 000 dispositifs Edge attribués.

  L'erreur d'Orchestrator indique « Erreur lors de la validation des modifications ». Le dispositif VMware SASE Orchestrator ne parvient pas à mettre à jour les paramètres VPN, car l'API attend une requête de base de données qui renvoie un excédent de 10 000 lignes. Cette situation peut se produire avec un Orchestrator fonctionnant à grande échelle. Ce problème est dû au fait que l'Orchestrator reçoit toutes les passerelles, quel que soit leur type (principal et secondaire), alors que seul le dispositif Edge devrait signaler sa passerelle principale. Cela augmente considérablement le nombre d'enregistrements renvoyés et peut faire déborder une requête à grande échelle.

• Problème résolu 118574 : Pour une entreprise cliente utilisant le service de pare-feu amélioré, une alerte peut être envoyée avec une gravité « informative », même si le score d'incidence est élevé.

  Une description de gravité inexacte peut induire un utilisateur client en erreur et compromettre sa capacité à réagir à l'alerte. Ce problème est dû au fait que les signatures ne sont pas correctement classées.

• Problème résolu 118673 : Lorsqu'un dispositif Edge VMware SD-WAN change de profil, l'exécution du processus peut prendre environ 60 secondes, avec le potentiel d'arriver complètement à expiration.

  Le changement de profil doit prendre quelques secondes, mais Orchestrator met beaucoup plus de temps à effectuer cette tâche en raison d'API incorrectement optimisées.

• Problème résolu 119551 : Pour les clients utilisant le service VMware Cloud Web Security, si un utilisateur tente de modifier un paramètre de Cloud Web Security sous Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration), la tentative échoue avec une erreur.

  Lorsque l'utilisateur clique sur Mettre à jour (Update), Orchestrator génère une erreur indiquant « Détails du service non valide » (Invalid Service details). Cela se produit, par exemple, à la suite d'une tentative de modification du type de licence de Cloud Web Security.

• Problème résolu 119733 : La base de données de VMware SASE Orchestrator peut subir une panne et nécessiter un redémarrage d'Orchestrator pour récupérer.

  Ce problème est dû au fait que la base de données ne dispose pas de la dernière version de MySQL et qu'Orchestrator version 5.2.0.1 corrige cette lacune avec une version de MySQL mise à jour.

Résolu dans R5200-20230529-GA

La version R5200-20230529-GA d'Orchestrator a été publiée le 31/05/2023 et résout les problèmes suivants depuis Orchestrator version R5104-20230426-GA.

Note:

La version 5.2.0 contient tous les correctifs d'Orchestrator répertoriés dans les Notes de mise à jour de la version 5.0.0 ou 5.0.1 et tous les correctifs d'Orchestrator dans les Notes de mise à jour de la version 5.1.0 jusqu'à la build susmentionnée.

• Problème résolu 50480 : Le texte dans les menus déroulants d'une nouvelle destination non-SD-WAN via un dispositif Edge est incorrect.

  Le menu déroulant de « Nouvelle destination non-SD-WAN via un dispositif Edge » (New Non SD-WAN Destination via Edge) indique :

  • Routeur IKEv1 générique (VPN basé sur un routeur)

  • Routeur IKEv2 générique (VPN basé sur un routeur)

  Il devrait indiquer « VPN basé sur une route » (Route Based VPN) avec un espacement approprié.

• Problème résolu 78572 : Un utilisateur opérateur peut configurer un profil d'opérateur avec un nom de domaine complet non valide et aucune erreur n'est générée.

  Orchestrator doit effectuer une validation sur la valeur du nom de domaine complet et, si ce dernier n'est pas valide, génère une erreur pour alerter l'opérateur. L'absence de cette validation risque d'entraîner une perte de connectivité du dispositif Edge à Orchestrator lorsque le profil d'opérateur est attribué au dispositif Edge.

• Problème résolu 78602 : Lorsqu'un utilisateur configure Syslog sur un profil et vérifie un dispositif VMware SD-WAN Edge qui utilise ce profil, il peut constater que le niveau Syslog ne s'affiche pas correctement.

  L'utilisateur observe qu'au lieu d'indiquer un niveau Syslog, l'interface utilisateur d'Orchestrator affiche uniquement « Erreur » (Error), même si la configuration Syslog est valide à partir du profil.

• Problème résolu 81514 : Lorsqu'une destination non-SD-WAN via une passerelle est configurée sur une instance d'Orchestrator 4.x qui est ensuite mise à niveau vers la version 5.x, la nouvelle interface utilisateur n'affiche pas la NSD sur la page Configurer (Configure) > Paramètres du périphérique (Device Settings).

  Ce problème est limité à la configuration de la NSD sur un dispositif Orchestrator 4.x et lors de l'utilisation de la nouvelle interface utilisateur. Une NSD configurée sur un dispositif Orchestrator 5.x ne présente pas ce problème.

• Problème résolu 83607 : Lorsqu'un utilisateur crée, met à jour ou supprime un groupe d'objets, VMware SASE Orchestrator ne génère aucun événement pour l'une de ces actions.

  Les utilisateurs doivent consulter les événements lorsqu'une modification est apportée à un groupe d'objets afin de pouvoir être contrôlés et audités par l'utilisateur qui a effectué la modification et les autres administrateurs de clients.

• Problème résolu 88661 : Lors de la configuration d'une destination non-SD-WAN via un dispositif Edge, l'utilisateur peut configurer une valeur PSK non valide qui peut entraîner la formation du tunnel.

  Orchestrator permet la saisie d'une valeur quelconque pour PSK, qu'il s'agisse d'un seul caractère ou de 100 caractères sans erreur générée.

• Problème résolu 93930 : La nouvelle interface utilisateur de VMware SASE Orchestrator autorise des valeurs non valides pour le préfixe AS-Path.

  Lors de la configuration d'un transfert de partenaire, puis de la configuration de BGP et des filtres BGP avec un préfixe AS-Path, l'utilisateur peut configurer des valeurs non valides et la nouvelle interface utilisateur ne valide ni ne génère d'erreur.

• Problème résolu 94610 : Lorsqu'un utilisateur lance un basculement HA forcé via Actions à distance (Remote Actions) > Forcer le basculement HA (Force HA Failover), VMware SASE Orchestrator ne peut pas générer et envoyer d'alerte pour le basculement HA.

  Le basculement HA étant forcé par Orchestrator, les deux dispositifs Edge (actif et en veille) anticipent le basculement, ce qui peut amener le dispositif Edge HA à envoyer les messages HA_GOING_ACTIVE et HA_READY dans la même pulsation. Si l'« état HA » (HA State) envoyé dans la pulsation indique « Prêt » (Ready), ceci induit en erreur Orchestrator qui ne génère pas d'alerte pour le basculement dans la mesure où le message « Prêt » (Ready) l'empêche de voir le message « En cours d'activation » (Going Active).

• Problème résolu 97014 : Lorsque vous utilisez la nouvelle interface utilisateur de VMware SASE Orchestrator et que vous accédez à Surveiller (Monitor) > Présentation du réseau (Network Overview) pour une entreprise cliente, la colonne « État du bastion » (Bastion State) n'est pas disponible.

  L'option « État du bastion » (Bastion State) est également manquante sur la page Moniteur de passerelles (Gateway Monitor) et, dans les deux cas, est visible sur l'interface utilisateur classique.

• Problème résolu 98241 : Lorsqu'un utilisateur active ou désactive le service Edge Network Intelligence sur la page Configuration du client (Customer configuration), VMware SASE Orchestrator génère une erreur, même si l'action était valide.

  L'erreur indique : « L'URL d'analyse doit être définie dans la propriété système (service.analytics.apiUrl) pour la fonctionnalité d'analyse ».(Analytics Url must be set in system property [service.analytics.apiUrl] for analytics feature). Le message d'erreur est trompeur et les modifications ont été enregistrées.

• Problème résolu 99065 : Dans la nouvelle interface utilisateur de VMware SASE Orchestrator, un utilisateur ne peut pas créer de service VNF sur la page VNF de sécurité du dispositif Edge (Edge Security VNF).

  L'utilisateur peut créer un service VNF via la page Services réseau (Network Services), mais le correctif ici permet également à l'utilisateur de le faire sur la page VNF de sécurité du dispositif Edge (Edge Security VNF).

• Problème résolu 99080 : Pour un utilisateur examinant la nouvelle interface utilisateur de VMware SASE Orchestrator avec le navigateur Apple Safari, sur la page Configurer la VNF de sécurité (Configure Security VNF), les menus d'options déroulants contiennent des options vides.

  Cela s'effectue uniquement sur les navigateurs Safari, et les navigateurs basés sur Chromium fonctionnent comme prévu.

• Problème résolu 99353 : VMware SASE Orchestrator permet à un utilisateur de configurer la même adresse IP du serveur pour plusieurs configurations de collecteur NetFlow.

  Orchestrator doit valider les adresses IP en double dans les paramètres NetFlow et refuser une adresse IP de serveur qui existe déjà.

• Problème résolu 99891 : Lorsqu'un administrateur partenaire se connecte à VMware SASE Orchestrator et utilise la nouvelle interface utilisateur, lorsqu'il se trouve sur la page Gérer les clients partenaires (Manage Partner Customers) et qu'il sélectionne Client (Customer) > Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration), il observe une erreur.

  Le message d'erreur indique « méthode d'accès non autorisée » (not allowed to method) lorsque l'administrateur partenaire tente d'accéder à la configuration du client, même s'il dispose de privilèges complets pour accéder à cette page.

• Problème résolu 100148 : Un super utilisateur opérateur ne peut pas modifier un rôle opérateur sans changer au préalable la description.

  Le super utilisateur opérateur doit pouvoir modifier le rôle fonctionnel d'un rôle Opérateur (Operator) sans avoir à modifier la description.

• Problème résolu 101129 : La section Clés SSH d'entreprise (Enterprise SSH Keys) est visible pour Support opérateur (Operator Support), Super utilisateur du partenaire (Partner Superuser) et Super utilisateur du client (Customer Superuser).

  Les rôles d'utilisateur répertoriés ne disposent pas des privilèges permettant de consulter ces informations et celles-ci ne doivent pas être visibles.

• Problème résolu 103066 : Lorsqu'une business policy est associée à une application dans une carte d'application et que cette application est supprimée ultérieurement de la carte d'application, un utilisateur ne peut pas apporter d'autres modifications à cette business policy.

  Un utilisateur doit pouvoir modifier la Business Policy, même si l'application associée à la stratégie a été supprimée de la carte d'application.

• Problème résolu 103620 : Dans la nouvelle interface utilisateur de VMware SASE Orchestrator, lors de la configuration de Paramètres de l'interface (Interface Settings) > OSPF > Paramètres avancés (Advanced Settings) > Apprentissage de route entrante (Inbound Route Learning), l'option « Correspondance exacte » (Exact Match) affiche une valeur « Vrai » (True) même si elle est en réalité définie sur « Faux » (False).

  Cela peut prêter à confusion et induire en erreur un utilisateur qui pense qu'un paramètre OSPF important est le contraire de ce qu'il est, ce qui peut entraîner des problèmes de routage.

• Problème résolu 104667 : Dans la nouvelle interface utilisateur de VMware SASE Orchestrator, lorsque vous examinez Surveiller (Monitor) > Dispositif Edge (Edge) > État du lien (Link Status), les informations sur la date sont incorrectes si le lien est marqué comme Instable (Unstable).

  Si un utilisateur clique sur l'info-bulle pour ce lien, la présentation peut signaler « Lien inactif : il y a 53 ans » (Link Down: 53 years ago), même s'il est actif, mais dégradé.

• Problème résolu 105580 : Pour un dispositif VMware SASE Orchestrator dans lequel le mode FIPS est configuré, une tentative de configuration de la récupération d'urgence (DR) pour Orchestrator peut échouer.

  La configuration de la récupération d'urgence avec FIPS configuré inclut une build d'Orchestrator avec MySQL version 8.0.28 ou ultérieure et échoue lors de la phase COPYING_DP de la récupération d'urgence avec une erreur SSL_CTX_new failed when trying to connect.

• Problème résolu 105861 : lorsqu'un lien WAN devient inactif pendant plusieurs minutes avant de redevenir actif, le graphique Surveiller (Monitor) > QoE ne présente pas en temps réel l'état du lien.

  La QoE doit s'afficher en rouge lorsque le lien devient inactif, puis reprendre sa couleur (verte si la qualité est bonne) lorsque le lien redevient actif, ce qui n'est pas le cas et engendre une certaine confusion pour les utilisateurs. Ce problème est dû au fait que la base de données du dispositif VMware SASE Orchestrator n'enregistre pas correctement l'événement de lien inactif.

• Problème résolu 106295 : Pour une destination non-SD-WAN avec un type AWS, lorsque des passerelles principale et secondaire sont configurées avec BGP configuré sur chacune d'elles, il se peut que VMware SASE Orchestrator affiche les tunnels secondaires redondants comme étant inactifs, même s'ils sont actifs.

  Du côté d'AWS, les tunnels primaire et secondaire sont signalés comme étant actifs, mais sur la page Surveiller (Monitor) > Services réseau (Network Services) de l'Orchestrator, le tunnel secondaire est indiqué comme étant inactif. Il s'agit d'un problème strictement superficiel.

• Problème résolu 106554 : Sur une nouvelle interface utilisateur de VMware SASE Orchestrator, lors de la création d'un dispositif VMware SD-WAN Edge, le dispositif Edge est toujours créé avec l'authentification Edge par défaut (Default Edge Authentication) définie sur « Acquisition de certificat » (Certficate Acquire), quelle que soit la configuration du paramètre « Certificat par défaut » (Default Certificate) par l'utilisateur sous Paramètres de service (Service Settings) > Gestion d'Edge (Edge Management).

  Si un utilisateur définit Certificat par défaut (Default Certificate) comme Certificat désactivé (Certificate Deactivated) ou Certificat requis (Certificate Required), la nouvelle interface utilisateur ignore ces paramètres globaux et configure le nouveau dispositif Edge comme Acquisition de certificat (Certificate Acquire). Problème non visible sur l'interface utilisateur classique.

• Problème résolu 107858 : Pour les clients configurant des API à utiliser sur VMware SASE Orchestrator, des clés JSON sont manquantes dans Swagger pour inside ha et device_settings_dhcp_relay.

  Les versions 5.2.0 et ultérieures incluent les clés JSON manquantes : propriétés inside ha et device_settings_dhcp_relay.

• Problème résolu 109710 : Un administrateur partenaire peut ne pas être en mesure de configurer un transfert de partenaire sur VMware SASE Orchestrator.

  Les utilisateurs administrateurs partenaires reçoivent l'erreur « impossible de définir la propriété v6Detail de type indéfini » (cannot set property v6Detail of undefined) lors de la configuration des routes statiques sur un transfert de partenaire au niveau de la passerelle. Les utilisateurs opérateurs peuvent effectuer la modification sans problème.

• Problème résolu 112912 : Sur un dispositif VMware SASE Orchestrator avec la nouvelle interface utilisateur, un utilisateur connecté avec un rôle « Support de l'entreprise » (Enterprise Support), l'option « Redémarrer » est grisée lorsque l'option « Actions à distance » (Remote Actions) est définie pour un dispositif Edge.

  Un utilisateur du Support de l'entreprise peut redémarrer un dispositif Edge à distance lors de l'utilisation de l'interface utilisateur classique et doit également pouvoir le faire sur la nouvelle interface utilisateur.

• Problème résolu 113209 : Un utilisateur ne peut pas supprimer un dispositif VMware SD-WAN Edge de SASE Orchestrator si le dispositif Edge est dans un état « Dégradé » (Degraded).

  Orchestrator génère un message d'erreur indiquant « Les dispositifs Edge dégradés et les dispositifs Edge connectés ne peuvent pas être supprimés » (Degraded edges and connected edges cannot be deleted). Bien qu'un utilisateur ne puisse pas supprimer un dispositif Edge connecté, il doit être en mesure de supprimer un dispositif Edge dégradé.

• Problème résolu 114224 : Sur VMware SASE Orchestrator, lors de l'utilisation de la nouvelle interface utilisateur, si un opérateur supprime l'intégration de Google Maps des propriétés système (System Properties) d'Orchestrator, la nouvelle interface utilisateur continue d'afficher Google Maps.

  Lorsqu'un utilisateur passe la propriété système service.client.googleMapsApi.enable sur false pour supprimer l'intégration de Google Maps pour un client sur site, vous devez supprimer l'intégration de Google Maps de la nouvelle interface utilisateur. Au lieu de cela, la modification s'applique uniquement à l'interface utilisateur classique.

• Problème résolu 114564 : l'utilisateur ne peut pas configurer le paramètre 802.1P dans la configuration facultative d'une interface Edge dans la nouvelle interface utilisateur de VMware SASE Orchestrator.

  Alors que ce paramètre est bien affiché en tant que configuration facultative dans l'interface utilisateur classique d'Orchestrator, il ne figure pas dans la nouvelle interface utilisateur qui est celle par défaut pour la version 5.2.0.

• Problème résolu 114900 : L'onglet « Destinations non-SD-WAN via un dispositif Edge » (Non SD-WAN Destinations via Edge) n'est pas visible pour les utilisateurs d'entreprise en lecture seule.

  Ce problème est dû au fait que les autorisations sont configurées de manière incorrecte pour le rôle d'utilisateur d'entreprise en lecture seule (Enterprise Read Only).

• Problème résolu 115527 : Lorsqu'un utilisateur configure une destination non-SD-WAN via un dispositif Edge avec un type Zscaler, aucun état de tunnel ne s'affiche lorsqu'il examine Surveiller (Monitor) > Dispositifs Edge (Edges) dans la nouvelle interface utilisateur de VMware SASE Orchestrator.

  L'API utilisée par la nouvelle interface utilisateur pour extraire les enregistrements de tunnel Edge part du principe erroné que la version logicielle d'Edge suit toujours le format « x.x.x » et exclut donc les données d'état du tunnel des dispositifs Edge dont la version ne respecte pas ce format (par exemple, 5.1.0.3).

• Problème résolu 115719 : Une règle de backhaul Internet n'est pas conservée dans la règle de Business Policy si des modifications sont apportées aux paramètres du périphérique (Device Settings) au niveau du profil.

  Orchestrator supprime par erreur la règle de backhaul lors d'une modification de la section Paramètres du périphérique (Device Settings) d'un profil.

• Problème résolu 116958 : Lors de l'utilisation de la nouvelle interface utilisateur de VMware SASE Orchestrator, un utilisateur opérateur peut observer un message d'erreur de l'API s'il accède à la page Événements d'opérateur (Operator Events).

  Ce problème est dû au fait que le cache d'événements des filtres ne supprime pas et ne partage pas toutes les pages Événements (Events). La page Événements d'entreprise (Enterprise Events) doit comporter des valeurs interdites pour les pages Opérateur (Operator) et Partenaire (Partner).

• Problème résolu 116976 : Pour les utilisateurs d'API sur VMware SASE Orchestrator, getEnterpriseEdgeLInkStatus peut ne pas répondre avec des liens qui ont été déconnectés pendant plus de 24 heures lorsque l'API est appelée avec les paramètres {"detailed": true} et que l'appelant est un administrateur partenaire.

  Une régression ajoutée dans la version 4.0.0 a modifié le comportement de l'API pour renvoyer UNIQUEMENT des liens récents pour les connexions de l'administrateur partenaire. Ce problème n'affecte pas les connexions de l'administrateur opérateur ou d'entreprise.

Problèmes connus

Problèmes ouverts dans la version 5.2.0.

• Problèmes connus liés à Edge/Gateway
• Problèmes connus d'Orchestrator

Problèmes connus liés à Edge/Gateway

• Problème 14655 :

  La connexion ou la déconnexion d'un adaptateur SFP peut amener le périphérique à cesser de répondre sur le dispositif Edge 540, Edge 840 et Edge 1000 et à nécessiter un redémarrage physique.

  Solution : Le dispositif Edge doit être redémarré physiquement. Cette opération peut être effectuée sur Orchestrator en utilisant Actions à distance (Remote Actions) > Redémarrer le dispositif Edge (Reboot Edge) ou en soumettant le dispositif Edge à un cycle d'alimentation.

• Problème 25504 :

  Les coûts des routes statiques supérieurs à 255 peuvent entraîner un classement imprévisible des routes.

  Solution : Utilisez un coût de route compris entre 0 et 255.

• Problème 25595 :

  Un redémarrage peut être nécessaire pour que les modifications apportées au SLA statique sur une superposition WAN fonctionnent correctement.

  Solution : Redémarrez le dispositif Edge après l'ajout et la suppression d'un SLA statique sur l'overlay WAN.

• Problème 25742 :

  Le trafic compté de sous-couche est limité à une capacité maximale vers la passerelle VMware SD-WAN Gateway, même si cette capacité est inférieure à la capacité d'une liaison WAN privée qui n'est pas connectée à la passerelle.

• Problème 25758 :

  Les liaisons WAN USB peuvent ne pas se mettre à jour correctement lorsqu'elles passent d'un port USB à un autre jusqu'au redémarrage du dispositif VMware SD-WAN Edge.

  Solution : Redémarrez le dispositif Edge après le déplacement des liaisons WAN USB d'un port à un autre.

• Problème 25885 :

  Une importante mise à jour de la configuration sur la passerelle partenaire (par exemple, 200 VRF configurés de BGP) peut entraîner une augmentation de la latence d'environ 2 à 3 secondes pour certains trafics via la passerelle VMware SD-WAN Gateway.

  Solution : Aucune solution disponible.

• Problème 25921 :

  Le basculement haute disponibilité de VMware SD-WAN Hub prend plus de temps que prévu (jusqu'à 15 secondes) lorsque 3 000 dispositifs Edge de site distant sont connectés au Hub.

  Solution : Aucune solution disponible.

• Problème 25997 :

  Le dispositif VMware SD-WAN Edge peut nécessiter un redémarrage pour acheminer correctement le trafic sur une interface routée qui a été convertie en port commuté.

  Solution : Redémarrez le dispositif Edge après avoir apporté la modification à la configuration.

• Problème 26421 :

  La passerelle partenaire principale pour n'importe quel site de site distant doit également être attribuée à un cluster de Hubs VMware SD-WAN pour que les tunnels vers le cluster soient établis.

  Solution : Aucune solution disponible.

• Problème 28175 :

  La NAT de Business Policy échoue lorsque l'adresse IP NAT chevauche l'adresse IP de l'interface de la passerelle VMware SD-WAN Gateway.

  Solution : Aucune solution disponible.

• Problème 31210 :

  VRRP : ARP n'est pas résolu dans le client LAN pour l'adresse IP virtuelle VRRP lorsqu'il s'agit d'un dispositif VMware SD-WAN Edge principal avec un segment CDE non global exécuté sur l'interface LAN.

  Solution : Aucune solution disponible.

• Problème 32731 :

  Les routes conditionnelles par défaut annoncées via OSPF peuvent ne pas être correctement retirées lorsque la route est désactivée.

  Solution : La réactivation de la route, puis sa nouvelle désactivation, la retirera avec succès.

• Problème 32960 :

  L'état de l'interface Négociation automatique (Autonegotiation) et Vitesse (Speed) peut s'afficher de manière incorrecte sur l'interface utilisateur Web locale pour les dispositifs VMware SD-WAN Edge activés.

  Solution : Reportez-vous à l'interface utilisateur d'Orchestrator sous Diagnostics à distance (Remote Diagnostics) > État de l'interface (Interface Status).

• Problème 32981 :

  La vitesse de codage en dur et le mode duplex sur un port configuré de DPDK peuvent nécessiter un redémarrage du dispositif VMware SD-WAN Edge pour que les configurations prennent effet, car l'opération nécessite la désactivation de DPDK.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 34254 :

  Lorsqu'un CSS Zscaler est créé et que les paramètres de nom de domaine complet/PSK sont configurés sur le segment global, ces paramètres sont copiés dans des segments non globaux pour former des tunnels IPsec vers un CSS Zscaler.

• Problème 35778 :

  Lorsque plusieurs liaisons WAN définies par l'utilisateur sont utilisées sur une interface, seule une de ces liaisons WAN peut disposer d'un tunnel GRE vers Zscaler.

  Solution : Utilisez une interface différente pour chaque liaison WAN qui doit créer des tunnels GRE vers Zscaler.

• Problème 36923 :

  Le nom du cluster ne peut pas être mis à jour correctement dans la description de l'interface NetFlow pour un dispositif VMware SD-WAN Edge qui est connecté à ce cluster comme son Hub.

• Problème 38682 :

  Un dispositif VMware SD-WAN Edge agissant comme un serveur DHCP sur une interface configurée par DPDK peut ne pas générer correctement des événements Nouveau périphérique client (New Client Device) pour tous les clients connectés.

• Problème 38767 :

  Lorsqu'une superposition WAN disposant de tunnels GRE vers Zscaler configurée passe de la détection automatique à la définition par l'utilisateur, les tunnels périmés peuvent être conservés jusqu'au prochain redémarrage.

  Solution : Redémarrez le dispositif Edge pour effacer le tunnel périmé.

• Problème 39374 :

  La modification de l'ordre des passerelles partenaire VMware SD-WAN attribuées à un dispositif VMware SD-WAN Edge peut ne pas définir correctement la passerelle (Gateway) 1 comme passerelle locale à utiliser pour les tests de bande passante.

• Problème 39608 :

  La sortie du test ping du diagnostic à distance peut afficher brièvement du contenu non valide avant d'afficher les résultats corrects.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 39624 :

  L'envoi d'une commande ping via une sous-interface peut échouer lorsque l'interface parente est configurée avec PPPoE.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 39753 :

  La désactivation d'un VPN de site distant à site distant dynamique peut entraîner l'envoi de flux existants à l'aide d'une relation site distant vers site distant dynamique pour le blocage.

  Solution : Désactivez uniquement le VPN dynamique site distant vers site distant dans une fenêtre de maintenance.

• Problème 40421 :

  Traceroute n'affiche pas le chemin d'accès lors du transfert d'un dispositif VMware SD-WAN Edge avec une interface configurée en tant que port commuté.

• Problème 40096 :

  Si un dispositif VMware SD-WAN Edge 840 est redémarré, un module SFP connecté au dispositif Edge cessera peut-être de transmettre le trafic même si les voyants de lien et VMware SD-WAN Orchestrator indiquent que le port est ACTIF (UP).

  Solution : Déconnectez le module SFP, puis reconnectez-le au port.

• Problème 42278 :

  Pour un type spécifique de mauvaise configuration de l'homologue, la passerelle VMware SD-WAN Gateway peut envoyer en continu des messages d'initialisation IKE à un homologue non-SD-WAN. Ce problème n'interrompt pas le trafic utilisateur vers la passerelle. Cependant, les journaux de la passerelle se rempliront avec des erreurs IKE et cela peut masquer des entrées de journal utiles.

• Problème 42872 :

  L'activation de l'isolation de profils sur un profil Hub dans lequel un cluster de Hubs est associé ne révoque pas les routes de Hub de la base d'informations de routage (RIB).

• Problème 43373 :

  Lorsque la même route BGP est apprise à partir de plusieurs dispositifs VMware SD-WAN Edge, si cette route est déplacée de sortie préférée à sortie éligible dans Contrôle de flux de superposition (Overlay Flow Control), le dispositif Edge n'est pas supprimé de la liste d'annonces et continue d'être annoncé.

  Solution : Activez le calcul du coût distribué (DCC) sur VMware SD-WAN Orchestrator.

• Problème 44995 :

  Les routes OSPF ne sont pas révoquées des passerelles VMware SD-WAN Gateway et des dispositifs VMware SD-WAN Spoke Edge lorsque les routes sont retirées du cluster de Hubs.

• Problème 45189 :

  Lors de la configuration d'un NAT source côté LAN, le trafic provenant d'un dispositif VMware SD-WAN Edge vers un Hub Edge est autorisé même sans la configuration de route statique pour le sous-réseau NAT.

• Problème 45302 :

  Dans un cluster de Hubs de VMware SD-WAN, si un Hub perd la connectivité pendant plus de 5 minutes vers toutes les passerelles VMware SD-WAN Gateway communes entre lui-même et ses dispositifs Spoke Edge associés, les Spokes peuvent dans de rares cas ne pas pouvoir conserver les routes de Hub après 5 minutes. Le problème se résout automatiquement lorsque le Hub reprend contact avec les passerelles.

• Problème 46053 :

  La préférence BGP n'est pas corrigée automatiquement pour les routes de superposition lorsque son voisin devient un voisin de liaison montante.

  Solution : Un redémarrage du service Edge corrigera ce problème.

• Problème 46137 :

  Un dispositif VMware SD-WAN Edge exécutant un logiciel 3.4.x n'établit pas de tunnel avec un chiffrement AES-GCM même si le dispositif Edge est configuré pour GCM.

  Solution : Si un client utilise AES-256, il doit explicitement désactiver GCM dans Orchestrator avant de mettre à niveau ses dispositifs Edge vers une version 4.x. Une fois que tous les dispositifs Edge exécutent une version 4.x, le client peut choisir entre AES-256-GCM et AES-256-CBC.

• Problème 46216 :

  Sur des destinations non SD-WAN via une passerelle ou un dispositif Edge sur lequel l'homologue est une instance d'AWS, lorsque l'homologue initie un renouvellement de clés de phase 2, l'IKE de phase 1 est également supprimé et impose un renouvellement de clés. Cela signifie que le tunnel est détruit et recréé, ce qui entraîne une perte de paquets lors de la reconstruction du tunnel.

  Solution : Pour éviter la destruction du tunnel, configurez les destinations non-SD-WAN via une passerelle/dispositif Edge ou un temporisateur de renouvellement de clés IPsec CSS défini à moins de 60 minutes. Cela empêche AWS de lancer le renouvellement de clés.

• Problème 46391 :

  Pour un dispositif VMware SD-WAN Edge 3800, les interfaces SFP1 et SFP2 présentent chacune des problèmes avec des SFP multivoie (c'est-à-dire 1/10G) et ne doivent pas être utilisées dans ces ports.

  Solution : Utilisez le mode SFP à taux unique conformément à l'article de la base de connaissances Liste de modules SFPpris en charge par VMware SD-WAN (79270). Les SFP à taux multiples peuvent être utilisés avec SFP3 et SFP4.

• Problème 47664 :

  Dans une configuration Hub et Spoke où le mode site distant à site distant via Hub VPN n'est pas configuré, la tentative d'inversion du trafic site distant à site distant à l'aide d'une route Résumé sur un commutateur/routeur L3 entraîne des boucles de routage.

  Solution : Configurez le VPN cloud pour activer le VPN site distant vers site distant et sélectionnez « Utiliser des Hubs pour le VPN » (Use Hubs for VPN).

• Problème 47681 :

  Lorsqu'un hôte côté LAN d'un dispositif VMware SD-WAN Edge utilise la même adresse IP que l'interface WAN de ce dispositif Edge, la connexion entre l'hôte LAN et le WAN ne fonctionne pas.

• Problème 48530 :

  Les dispositifs VMware SD-WAN Edge modèles 6x0 n'effectuent pas de négociation automatique pour les SFP en cuivre à triple vitesse (10/100/1 000 Mbits/s).

  Solution : Le dispositif Edge 520/540 prend en charge les SFP en cuivre à triple vitesse, mais ce modèle a été marqué pour fin de commercialisation au 1er trimestre 2021.

• Problème 48597 : Le BGP Neighborship à multihop ne reste pas actif si l'un des deux chemins vers le peer tombe en panne.

  S'il existe un BGP Neighborship à multihop avec un homologue accessible à partir de plusieurs chemins et si l'un d'entre eux tombe en panne, l'utilisateur remarque la panne de BGP Neighborship et ne s'active pas à l'aide d'autres chemins d'accès disponibles. Cela inclut également le cas du voisinage à bouclage d'adresse IP locale.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 50518 :

  Sur une passerelle VMware SD-WAN Gateway sur laquelle PKI est configurée, si plus de 6 000 tunnels PKI tentent de se connecter à la passerelle, les tunnels peuvent ne pas s'afficher, car les SA entrants ne sont pas supprimés.

  Note:

  Les tunnels utilisant l'authentification par clé prépartagée (PSK) ne présentent pas ce problème.

• Problème 51436 : Pour un site utilisant la topologie de haute disponibilité améliorée lors du déploiement d'un dispositif VMware SD-WAN Edge à l'aide d'un modem LTE, le basculement de HA prend environ entre 5 et 6 minutes si le site passe à un état « split-brain ».

  Dans le cadre de la récupération à partir d'un état Split-Brain, les ports LAN sont désactivés sur le dispositif Edge actif et cela a une incidence sur le trafic LAN pendant la période d'inactivité des ports et jusqu'à la récupération du site.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 52955 : Le refus DHCP n'est pas envoyé à partir du dispositif Edge et la reliaison DHCP n'est pas redémarrée après un échec DAD dans DHCP avec état.

  Si le serveur DHCPv6 alloue une adresse détectée en double par le noyau lors d'une vérification DAD, le client DHCPv6 n'envoie aucun refus. Cela entraîne l'abandon du trafic, car l'adresse de l'interface est marquée comme échec de la vérification DAD et n'est pas utilisée. Cela n'entraîne aucun bouclage de trafic dans le réseau, mais un blocage du trafic sera observé.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 53219 : Après le rééquilibrage d'un cluster de Hub VMware SD-WAN, l'interface/IIF RPF ne sera peut-être pas définie correctement sur les quelques dispositifs Spoke Edge.

  Le trafic multicast sera affecté sur les dispositifs Spoke Edge concernés. Après un rééquilibrage du cluster, certains dispositif Edge Spoke ne parviennent alors pas à envoyer une jonction PIM.

  Solution : Ce problème persiste jusqu'au redémarrage du service Edge pour le dispositif Spoke Edge concerné.

• Problème 53934 : Dans une entreprise dans laquelle un cluster Hub VMware SD-WAN est configuré, si le Hub principal dispose de voisinages BGP à multihop côté LAN, le client peut subir des abandons de trafic sur un dispositif Spoke Edge en cas de panne de LAN ou lorsque BGP n'est pas configuré sur tous les segments.

  Dans un cluster Hub, le Hub principal dispose d'un BGP Neighborship à multihop avec un périphérique homologue pour apprendre des routes. Si l'interface physique sur le Hub par lequel le BGP Neighborship est établi tombe en panne, les routes LAN BGP peuvent ne pas passer à zéro, bien que la vue BGP soit vide. Cela peut éviter le rééquilibrage du cluster Hub. Ce problème peut également être observé lorsque BGP n'est pas configuré pour tous les segments et lorsqu'il existe un ou plusieurs BGP Neighborships à multihop.

  Solution : Redémarrez le hub dont le LAN était en panne (ou le protocole BGP non activé).

• Problème 57210 : Même lorsqu'un dispositif VMware SD-WAN Edge fonctionne normalement et est en mesure d'accéder à Internet, le voyant sur la page Présentation (Overview) de l'interface utilisateur locale est rouge.

  L'interface utilisateur locale du dispositif Edge détermine la connectivité du dispositif Edge en fonction de sa capacité à résoudre un nom connu via le résolveur DNS de Google (8.8.8.8). S'il ne peut pas le faire pour une raison quelconque, il considère qu'il est hors ligne et indique le voyant en rouge.

  Solution : Il n'existe aucune solution à ce problème, sauf de s'assurer que le trafic DNS vers la version 8.8.8.8 peut atteindre la destination et être résolu.

• Problème 61543 : En cas de configuration de plusieurs règles NAT 1:1 sur différentes interfaces disposant de la même adresse IP interne, le trafic entrant peut être reçu sur une seule interface et les paquets sortants du même flux peuvent être acheminés via une interface différente.

  Pour les flux NAT de l'extérieur vers l'intérieur, les règles NAT 1:1 sont mises en correspondance avec l'adresse IP externe et l'interface sur laquelle les paquets sont reçus. Pour les paquets sortants du même flux, le dispositif VMware SD-WAN Edge tente à nouveau de faire correspondre les règles NAT en comparant l'adresse IP interne. Le trafic sortant peut alors être acheminé via l'interface configurée dans la première règle correspondante avec l'option Trafic sortant (Outbound Traffic) configurée.

  Solution : il n'existe aucune solution à ce problème en dehors de la vérification de la configuration d'une seule règle NAT 1:1 avec une adresse IP interne particulière.

• Problème 65560 : Le trafic d'un client vers le périphérique PE (Provider Edge) échoue.

  Le BGP Neighborship entre une passerelle de partenaires et un dispositif Edge fournisseur n'est pas établi lorsque le type de balise est sélectionné comme « aucun » (none) dans la configuration de transfert. Cela est dû au fait que les valeurs ctag et stag sont choisies à partir de /etc/config/gatewayd au lieu de la configuration de transfert sur Orchestrator lorsque le type de balise est « aucun » (none).

  Solution : Mettez à jour les valeurs ctag, stag sur 0 sous vrf_vlan->tag_info dans /etc/config/gatewayd. Redémarrez vc_procmon.

• Problème 67879 : Un tunnel CSS (Cloud Security Service) est supprimé après qu'un utilisateur modifie un paramètre de superposition WAN de détection automatique (auto-detect) en défini par l'utilisateur (user-defined) sur un paramètre d'interface WAN.

  Après l'enregistrement des modifications, les tunnels CSS ne sont pas sauvegardés tant que le client n'arrête pas le tunnel, puis le sauvegarde. La modification de la configuration WAN arrêtera le tunnel CSS et analysera à nouveau la configuration CSS. Cependant, dans certains cas, le paramètre nvs_config>num_gre_links est égal à 0 et le tunnel CSS ne parvient pas à s'afficher.

  Solution : Désactivez la configuration CSS, puis réactivez-la, ce qui activera le tunnel CSS.

• Problème 68057 : Le paquet de version DHCPv6 n'est pas envoyé à partir du dispositif VMware SD-WAN Edge lors de la modification d'un mode d'adresse d'interface WAN d'une adresse IPv6 avec état DHCP à statique et le bail reste actif jusqu'à atteindre sa date de validité.

  Le client DHCPv6 possède un bail qu'il ne libère pas lorsque la modification de la configuration est effectuée. Le bail reste valide jusqu'à l'expiration de sa durée de vie dans le serveur DHCPv6 et est supprimé.

  Solution : Il n'est pas possible de corriger ce problème, car le bail restera actif tout au long de sa durée de vie.

• Problème 68851 : Si VMware SD-WAN Edge et VMware SD-WAN Gateway disposent chacun du même serveur Syslog TCP configuré, la connexion TCP n'est pas établie du dispositif Edge au serveur Syslog.

  Si le dispositif Edge et la passerelle disposent chacun du même serveur TCP et si les paquets Syslog du dispositif Edge sont acheminés via la passerelle, le serveur Syslog envoie une réinitialisation TCP au dispositif Edge.

  Solution : Envoyez les paquets Syslog directement à partir du dispositif Edge au lieu d'effectuer un routage via une passerelle ou configurez un serveur Syslog différent pour le dispositif Edge et la passerelle.

• Problème 69284 : Pour un site utilisant une topologie haute disponibilité dans laquelle les dispositifs Edge déploient des VNF dans une configuration HA et utilisent la version 4.x, si ces dispositifs Edge HA sont rétrogradés vers une version 3.4.x dans laquelle les VNF HA ne sont pas prises en charge, puis mis à niveau vers la version 4.5.0, lorsque les VNF HA sont réactivées, la VNF du dispositif Edge en veille ne s'affiche pas.

  L'état de la VNF sur le dispositif Edge en veille est communiqué comme étant inactif via le protocole simple de gestion de réseau. Si la paire VNF HA est rétrogradée d'une version prenant en charge VNF-HA (version 4.0+) vers une version qui ne la prend pas en charge avec la VNF configurée sur Orchestrator. Ce problème se produit lorsque le dispositif Edge est mis à niveau vers une version prenant en charge VNF-HA et qu'il est de nouveau configuré sur Orchestrator.

  Solution : La VNF doit d'abord être désactivée en cas de configuration HA si le dispositif Edge est rétrogradé vers une version qui ne la prend pas en charge.

• Problème 72358 : Si l'adresse IP du nom DNS d'un dispositif VMware SD-WAN Orchestrator change, le processus du plan de gestion de la passerelle VMware SD-WAN Gateway ne parvient pas à la résoudre correctement et la passerelle ne pourra pas se connecter à Orchestrator.

  Le processus de gestion de la passerelle vérifie périodiquement la résolution DNS du

  nom DNS d'Orchestrator, pour voir s'il a été modifié récemment, afin que la passerelle puisse se connecter à l'hôte approprié. Le code de résolution DNS présente un problème, de sorte que toutes ces vérifications de résolution échouent et la passerelle continue d'utiliser l'ancienne adresse et ne peut donc plus se connecter à Orchestrator.

  Solution : Tant que ce problème n'est pas résolu, un utilisateur opérateur ne doit pas modifier l'adresse IP d'Orchestrator. Si l'adresse IP d'Orchestrator doit être modifiée, toutes les passerelles se connectant à cette instance d'Orchestrator devront être réactivées.

• Problème 77541 : Lorsqu'un modem USB prenant en charge IPv6 est débranché, puis rebranché à une interface USB VMware SD-WAN Edge, une adresse IPv6 peut ne pas être provisionnée sur l'interface USB.

  Cela affecte les modems USB basés sur l'adresse IP plutôt que d'être gérés par l'application ModemManager. La plupart des modems Inseego sont basés sur l'adresse IP et cela est important, car Inseego est le fabricant de modems recommandé par VMware SASE. Les modems USB prenant en charge IPv6 qui utilisent ModemManager plutôt que d'être basés sur l'adresse IP seront idéaux dans un scénario de débranchement et de branchement.

  Solution : Le dispositif Edge doit être redémarré (ou faire d'objet d'un cycle d'alimentation) une fois le modem USB rebranché sur le port USB du dispositif Edge. Après le redémarrage, le dispositif Edge récupère l'adresse IPv6 du modem.

• Problème 81852 : Pour un dispositif VMware SD-WAN Edge qui utilise un service de sécurité cloud (CSS) de type Zscaler qui utilise des tunnels GRE ayant activé le contrôle de santé L7, le client peut observer des erreurs de contrôle de santé L7 dans certains cas lorsque ce dispositif Edge est mis à niveau vers la version 5.0.0.

  Cela s'observe généralement lors de la mise à niveau logicielle ou du démarrage. Lorsque le contrôle de santé L7 d'un CSS utilisant des tunnels GRE est activé, des messages d'erreur liés à l'erreur getaddress du socket peuvent s'afficher. L'erreur observée s'affiche par intermittence et n'est pas cohérente. De ce fait, les messages de sonde du contrôle de santé L7 ne sont pas envoyés.

  Solution : Sans le correctif, un utilisateur doit désactiver, puis réactiver la configuration du contrôle de santé L7 pour corriger le problème. Cette fonctionnalité fonctionnera alors comme prévu.

• Problème 82184 : Sur un dispositif VMware SD-WAN Edge qui exécute la version 5.0.0 du dispositif Edge, lorsqu'un traceroute ou traceroute6 est exécuté sur l'adresse IPv4/IPv6 de br-network du dispositif Edge, le traceroute ne s'arrête pas correctement lorsqu'une sonde UDP est utilisée.

  Traceroute ou traceroute6 vers l'adresse IPv4/IPv6 de br-network du dispositif Edge ne s'arrête pas correctement lorsque le mode par défaut (autrement dit, la sonde UDP) est utilisé.

  Solution : Utilisez l'option -I dans traceroute et traceroute6 pour utiliser la sonde ICMP, puis le traceroute vers l'adresse IPv4/IPv6 de br-network fonctionnera comme prévu.

• Problème 85402 : Pour une entreprise cliente utilisant BGP avec des passerelles de partenaires configurées, un utilisateur peut observer que certains voisinages BGP sont inactifs, ce qui entraîne des problèmes de trafic client.

  Si le client dispose d'un préfixe maximal configuré sur un routeur équipé d'un appairage BGP avec le dispositif Edge et la passerelle, il se peut que la session BGP soit abandonnée par le routeur.

  Par exemple, si BGP est configuré sur le routeur pour recevoir uniquement un nombre maximal de préfixes « n », mais que le dispositif Edge et la passerelle disposent d'un nombre de préfixes supérieur à « n » à annoncer en l'absence de filtres. Désormais, si la configuration du filtre BGP est modifiée sur Orchestrator, même si le nombre total de préfixes autorisés dans la direction sortante est inférieur à « n », le problème se produit lorsque plus de « n » préfixes sont envoyés au peer avant l'application de filtres. Cela entraîne l'arrêt de la session par le routeur.

  Solution : Si BGP tombe en panne en raison de ce problème (nombre maximal de préfixes atteint), bloquez BGP sur le peer à l'aide de l'interface CLI (pour FRR/Cisco, « neighbor x shut », suivi de « no neighbor x shut ») et le BGP produit uniquement le nombre souhaité de préfixes annoncés au peer.

• Problème 92481 : Si une interface WAN sur un dispositif VMware SD-WAN Edge est désactivée sur VMware SASE Orchestrator, SNMP signale toujours l'interface comme « Active » (UP).

  Le processus de débogage clé pour la sortie des interfaces n'inclut pas les détails du port physique pour les interfaces WAN du dispositif Edge (par exemple, GE3 ou GE4 sur un modèle Edge 6x0 ou 3x00). Par conséquent, lorsque SNMP interroge ces interfaces, il renvoie toujours un résultat Actif (UP), quel que soit le mode de configuration de ces interfaces.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 95399 : Une liaison Ethernet est physiquement débranchée ou branchée sur une interface VMware SD-WAN Edge. VMware SASE Orchestrator ne reçoit pas de notification de cet événement du dispositif Edge et ne s'affiche pas dans les événements du client.

  Les clients s'appuient sur Orchestrator pour signaler ces événements sur la page Événements et, lorsqu'ils ne sont pas enregistrés, la surveillance de leurs différents sites devient plus fiable.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 97559 : Sur un site client déployé avec une topologie à haute disponibilité améliorée, un lien WAN connecté au dispositif VMware SD-WAN Edge dans un rôle passif peut s'afficher comme étant inactif sur VMware SASE Orchestrator et ne pas transmettre le trafic client, même si l'interface WAN du dispositif Edge sur laquelle le lien WAN est connecté est actif.

  Un utilisateur examinant la journalisation d'une valeur tcpdump ou d'un bundle de diagnostics observe les demandes ARP entrantes et le dispositif Edge passif qui ne répond pas suite au blocage de son port. Dans la haute disponibilité (HA) améliorée, lorsqu'un dispositif Edge assume le rôle passif, les événements suivants doivent se produire dans l'ordre :

  1. Le dispositif Edge passif bloque tous les ports.

  2. Le dispositif Edge passif détecte ensuite qu'il est déployé dans la haute disponibilité (HA) améliorée et débloque ses ports WAN pour transmettre le trafic.

  Lorsque ce problème se produit, l'événement 1, le blocage de port initial dure inopinément longtemps et l'événement de suivi 2, le déblocage de tous les ports WAN est effectué avant la fin de l'événement 1. Ensuite, l'événement 1 se termine et, par conséquent, le blocage de tous les ports WAN sur le dispositif Edge passif correspond à l'état final.

  Solution : Sur un dispositif Edge HA sans correctif pour ce problème, la solution consiste à forcer un basculement HA qui promeut le dispositif Edge passif en actif pour mettre en place le ou les liens WAN du dispositif Edge HA.

• Problème 98136 : Pour les entreprises clientes utilisant une topologie Hub/Spoke dans laquelle un VPN dynamique site distant vers site distant est configuré, les utilisateurs clients derrière un dispositif SD-WAN Spoke Edge peuvent observer qu'une partie du trafic présente une latence inattendue résultant du trafic utilisant un chemin sous-optimal.

  Le trafic du dispositif Spoke Edge qui rencontre ce problème utilise une route qui était initialement une route sans liaison montante pour un dispositif Hub Edge non inclus dans le profil que le dispositif Spoke Edge utilisait. Un tunnel VPN dynamique site distant vers site distant peut se former du dispositif Spoke Edge vers le dispositif Hub Edge en raison de l'envoi du trafic vers un autre préfixe non lié. Dans cette instance, la route sans liaison montante est alors installée dans le dispositif Spoke Edge.

  Suite à cette route sans liaison montante, tout le trafic vers ce préfixe commence à transiter par

  le dispositif Hub Edge, et la route sans liaison montante devient une route avec liaison montante (remplacement de la communauté par la communauté de liaison montante). Toutefois, la route sans liaison montante installée précédemment n'est pas révoquée, et le trafic prend le chemin d'accès au dispositif Hub Edge tant que le tunnel VPN dynamique site distant vers site distant reste actif.

  Solution : Attendez le démontage du tunnel VPN dynamique site distant vers site distant, après quoi la route avec liaison montante n'est pas installée dans le dispositif Spoke Edge lorsqu'un nouveau tunnel VPN dynamique site distant vers site distant se forme vers le dispositif Hub Edge.

• Problème 106289 : Il se peut qu'un dispositif VMware SD-WAN Hub Edge abandonne des paquets sur les flux vers des dispositifs Spoke Edge connectés ou des flux de backhaul.

  L'indicateur de flux backhaul est défini lors du processus de synchronisation QoS : il existe un emplacement dans le code dans lequel il le définit lors de la création de flux. Le dispositif Edge ne doit définir cet indicateur que suite au traitement des messages de synchronisation QoS.

  Solution : Si ce problème se produit sur un dispositif Hub Edge sans correctif, videz les flux sur le dispositif Hub Edge pour corriger temporairement le problème.

• Problème 109771 : Un dispositif VMware SD-WAN Edge peut ne pas être en mesure d'établir un tunnel avec une destination non-SD-WAN via un dispositif Edge de type Cisco CSR/ASE lorsque NAT66 est appliqué entre temps.

  Si une NAT d'adresse IPv6 source est impliquée entre deux peers avec Cisco CSR/ASA, aucun tunnel n'est établi.

  Solution : Sur un dispositif Edge sans correctif pour ce problème, l'utilisateur doit se contenter de mettre à niveau Cisco CSR/ASA vers une version du logiciel Cisco qui prend en charge NAT66 sur IPsec.

• Problème 110561 : Les tunnels dynamiques peuvent ne pas s'activer entre le même ensemble de dispositifs VMware SD-WAN Edge avec un trafic bidirectionnel lorsque le trafic s'arrête, puis redémarre.

  Le problème s'observe dans un environnement de test dans lequel il existe 6 000 tunnels dynamiques avec un trafic bidirectionnel élevé envoyé entre les dispositifs Edge. Même lors d'essais à plus faible échelle sur 1 000 tunnels dynamiques, ces derniers ne s'activent pas tous.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 111085 : Lorsqu'un lien WAN du dispositif VMware SD-WAN Edge est configuré avec une adresse IP dans le même réseau que l'adresse IP Loopback du dispositif Edge, le dispositif Edge utilise l'adresse MAC de l'interface WAN tout en répondant à une demande ARP pour l'adresse IP Loopback du dispositif Edge.

  Cela peut entraîner une usurpation ARP et l'obsolescence de l'adresse IP de gestion, ainsi que des interruptions du réseau en conséquence.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 113877 : Pour les clients qui configurent le LAN BGP/GRE, ceux qui utilisent TGW GRE rencontrent des bagotements de BGP et une interruption du trafic sur le tunnel secondaire de TGW dans tous les segments lorsque la configuration BGP pour TGW GRE est modifiée sur le segment global.

  Lorsque le client modifie une configuration BGP de TGW GRE sur le segment global, le tunnel secondaire dans le segment global et les autres segments deviennent instables, ce qui entraîne une réinitialisation de la connexion BGP, une reconvergence et une interruption du trafic. La connexion BGP se formera à nouveau et le trafic sera restauré.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 117037 : pour un client utilisant une topologie Hub/Spoke dans laquelle plusieurs liens WAN sont utilisés pour envoyer et recevoir le trafic du dispositif Spoke Edge vers le dispositif Hub Edge, les clients peuvent observer des performances inférieures à celles attendues pour le trafic dirigé par les business policies, car les liens WAN n'agrègent pas la bande passante du lien WAN.

  SD-WAN utilise un compteur pour comptabiliser le nombre de paquets mis en mémoire tampon dans une file d'attente de reséquencement. Ce compteur, géré par peer, permet de s'assurer que seuls 4 000 paquets sont mis en mémoire tampon par peer. Sous certaines conditions, ce compteur peut devenir négatif. Avant la version 4.2.x, lorsque ce compteur devenait négatif, le compteur respectif était immédiatement réinitialisé à 0 après le vidage des paquets dans la file d'attente de reséquencement. Cependant, à partir de la version 4.3.x, ce compteur est mis à jour automatiquement afin de rester dans les limites attendues.

  En raison de ce changement de comportement, il peut arriver que la comptabilité des compteurs soit incorrecte et que la file d'attente de reséquencement reste à un nombre très élevé, forçant SD-WAN à vider chaque paquet. Cette action empêche l'agrégation de bande passante, mais peut également réduire l'efficacité des flux qui se trouveraient autrement sur un lien unique.

  Solution : Sur les dispositifs Edge sans correctif pour ce problème, la solution consiste à configurer des business policies qui dirigent le trafic correspondant vers un lien obligatoire unique.

• Problème 117314 : si un flux ICMP existe déjà entre une paire d'adresses IP source et de destination, une règle de pare-feu utilisant un groupe d'objets/de services (type et code) pour filtrer les paquets ICMP peut ne pas fonctionner.

  Dans le cadre d'une révision de la fonctionnalité de pare-feu, les modifications introduites pour la mise en cache du type et du code ICMP ont été annulées, ce qui a eu une incidence sur les règles de pare-feu qui utilisaient un groupe de services avec un type et un code ICMP (par exemple, ICMP avec un type de redirection égal à 5 et un code égal à 0). Si un flux est déjà présent entre une adresse IP source et une adresse IP de destination, le trafic ICMP qui doit correspondre aux règles de ce flux n'est pas respecté, et seuls les premiers paquets d'une session correspondent aux règles de pare-feu. Le problème affecte les flux ICMP IPv4 ou IPv6.

  Solution : videz les flux pour créer des flux ICMP et corriger temporairement le problème.

• Problème 117876 : Dans un site client utilisant une topologie à haute disponibilité, si un utilisateur active ou désactive les services de pare-feu améliorés (Enhanced Firewall Services), un dispositif VMware SD-WAN HA Edge peut subir plusieurs redémarrages.

  Lorsque l'option Services de pare-feu améliorés (Enhanced Firewall Services) est activée ou désactivée, seule la configuration des paramètres du périphérique (Device Settings) du dispositif Edge actif est synchronisée immédiatement avec le dispositif Edge passif : le reste de la synchronisation de la configuration répond uniquement à un signal de pulsation du dispositif Edge passif. Lorsque le dispositif Edge actif est redémarré pour appliquer la dernière configuration avant de recevoir un signal de pulsation du dispositif Edge passif, cela entraîne une incompatibilité de configuration entre les deux dispositifs Edge HA et ils subissent plusieurs redémarrages pour terminer la synchronisation de la configuration.

  Solution : La seule solution consiste à activer ou à désactiver les services de pare-feu améliorés (Enhanced Firewall Services) pour les dispositifs Edge HA pendant une fenêtre de maintenance.

• Problème 121606 : les entreprises clientes utilisant des passerelles de partenaires peuvent observer l'abandon d'une partie du trafic, notamment au niveau des destinations non-SD-WAN utilisant cette passerelle.

  Les passerelles de partenaires versions 5.1.0 et ultérieures prennent en charge 64 adresses IP au maximum par interface IPsec. Pour une passerelle de partenaire, les adresses IP de transfert sont ajoutées sans condition à cette interface IPsec. Si la limite de 64 adresses IP de transfert est dépassée, les anciennes adresses IP sont remplacées sur le processus IPsec, ce qui entraîne la panne des tunnels utilisant ces adresses IP remplacées.

  Solution : Si toutes les adresses IP de transfert de passerelle partenaire sont configurées comme prévu, la seule solution consiste à déplacer certaines de ces adresses vers une autre PG (par exemple, déplacement d'une NSD via une passerelle). Cependant, si des adresses IP de transfert PG sont inutiles, leur suppression peut s'avérer intéressante si cette action entraîne la réduction du nombre total d'adresses IP de transfert à 63 maximum. Après une modification de la configuration, le service de passerelle doit être redémarré.

• Problème 121998 : pour un client utilisant le pare-feu avec état dans une topologie Hub/Spoke, le trafic qui correspond à une règle de pare-feu configurée pour le trafic Spoke-vers-Hub et incluant un VLAN source peut être abandonné.

  En cas de modification de la version d'une table de stratégies de pare-feu, d'une classification d'application ou d'une table de business policy, SD-WAN effectue une recherche de flux de pare-feu sur son paquet suivant. En raison d'un problème de synchronisation, ce paquet peut provenir du côté du trafic de gestion (VCMP). Par conséquent, lors de la création d'une clé de recherche de stratégie de pare-feu, SD-WAN échange le VLAN du dispositif Spoke Edge avec le VLAN du dispositif Hub Edge, ce qui entraîne une non-correspondance avec la règle et l'abandon de ce trafic.

  Solution : Un client peut remplacer la Source d'un VLAN de dispositif Edge par « Indifférent » (Any).

• Problème 125274 : lorsqu'un client exécute une commande SNMP walk, l'interface de bouclage du dispositif VMware SD-WAN Edge n'est pas découverte.

  L'interface de bouclage du dispositif Edge est une catégorie d'interface unique que le dispositif Edge ne classe ni comme WAN ni comme LAN. Par conséquent, l'interface de bouclage ne figure pas dans la liste autorisée des interfaces à traiter pour snmp-request.

  Solution : Il n'existe aucune solution à ce problème. L'état de l'interface de bouclage doit être surveillé individuellement via l'interface utilisateur d'Orchestrator.

• Problème 125421 : Un client peut observer que les liens WAN sur un dispositif VMware SD-WAN Edge s'affichent par intermittence comme inactifs, puis actifs sur la page Surveillance et événements (Monitoring and Events) de l'interface utilisateur de VMware SASE Orchestrator, avec le risque que le dispositif Edge ne réponde plus et ne parvienne pas à transmettre le trafic jusqu'à ce qu'il soit redémarré manuellement, ou que le dispositif Edge puisse rencontrer une panne et un redémarrage du service de plan de données.

  Il s'agit d'un problème de fuite de mémoire du dispositif Edge qui se produit lorsque le service de plan de données du dispositif Edge ne peut pas ouvrir la mémoire partagée, ce qui entraîne des PI périmées. Cela entraîne à son tour l'épuisement du descripteur de fichiers ouverts, ce qui aura une incidence au départ sur les liens WAN. Toutefois, si ce problème est suffisamment avancé et entraîne l'épuisement de la mémoire du dispositif Edge, ce dernier peut :

  1. Ne plus répondre et devenir inaccessible via Orchestrator, ce qui nécessite un cycle de redémarrage/d'alimentation sur site.

  2. Déclencher une panne du service Edge avec un fichier noyau généré, le dispositif Edge redémarrant pour reprendre.

  Solution : Si vous observez ce problème pour la première fois, planifiez un redémarrage du service Edge dans une fenêtre de maintenance avant que le problème ne s'aggrave.

• Problème 134374 : les règles du pare-feu entrant associées à l'interface CELL d'un dispositif VMware SD-WAN Edge ne sont pas appliquées comme prévu dans une séquence.

  Si l'interface CELL du dispositif Edge n'a pas encore été créée ou n'est pas active (par exemple, aucune carte SIM insérée), lorsque la configuration du pare-feu est analysée, la valeur de l'interface CELL n'est pas renseignée correctement pour la règle de pare-feu et le trafic ne correspond pas à la règle.

  Solution : supprimez la règle et recréez-la une fois l'interface CELL active.

Problèmes connus d'Orchestrator

• Problème 21342 :

  Lors de l'attribution de passerelles partenaires par segment, la liste des attributions de passerelle peut ne pas s'afficher sous l'option d'opérateur Afficher (View) dans la liste de surveillance du dispositif VMware SD-WAN Edge.

• Problème 24269 :

  Surveiller (Monitor) > Transport > Perte (Loss) n'indique pas dans le graphique la perte de lien WAN observée tandis que les graphiques QoE reflètent cette perte. 

• Problème 25932 :

  VMware SD-WAN Orchestrator permet la suppression de passerelles VMware SD-Gateway du pool de passerelles, même lorsqu'elles sont en cours d'utilisation.

• Problème 32335 :

  La page Contrat de service de l'utilisateur final (End User Service Agreement) (CSUF) génère une erreur lorsqu'un utilisateur tente d'accepter le contrat.

  Solution : Assurez-vous qu'aucun espace de début ou de fin n'est présent dans le nom de l'entreprise.

• Problème 32435 :

  Un remplacement du dispositif VMware SD-WAN Edge pour une configuration NAT basée sur des stratégies est autorisé pour les tuples qui sont déjà configurés au niveau du profil et inversement.

• Problème 32856 :

  Bien qu'une business policy soit configurée pour utiliser le cluster de Hubs pour le backhaul du trafic Internet, l'utilisateur peut annuler la sélection du cluster de Hubs d'un profil sur une instance de VMware SD-WAN Orchestrator qui a été mise à niveau de la version 3.2.1 vers la version 3.3.x.

• Problème 35658 :

  Lorsqu'un dispositif VMware SD-WAN Edge est déplacé d'un profil vers un autre qui a un paramètre CSS différent (par exemple, IPsec dans le profil 1 vers GRE dans profil 2), les paramètres CSS de niveau Edge continueront à utiliser les paramètres CSS précédents (par exemple, IPsec et non GRE). 

  Solution : Au niveau du dispositif Edge, désactivez GRE, puis réactivez GRE pour résoudre le problème.

• Problème 35667 :

  Lorsqu'un dispositif VMware SD-WAN Edge est déplacé d'un profil vers un autre avec le même paramètre CSS, mais un nom CSS GRE différent (les mêmes points de terminaison), certains tunnels GRE ne s'affichent pas dans la surveillance.

  Solution : Au niveau du dispositif Edge, désactivez GRE, puis réactivez-le pour résoudre le problème.

• Problème 36665 :

  Si VMware SD-WAN Orchestrator ne peut pas accéder à Internet, les pages de l'interface utilisateur qui nécessitent l'accès à l'API Google Maps peuvent ne pas se charger complètement.

• Problème 32913 :

  Après l'activation du mode haute disponibilité, les détails de la multicast du dispositif VMware SD-WAN Edge ne s'affichent pas sur la page Surveillance. Un basculement résout le problème.

• Problème 33026 :

  La page Contrat de service de l'utilisateur final (End User Service Agreement) (CSUF) ne se recharge pas correctement après la suppression de l'accord.

• Problème 38056 :

  Le fichier Edge-Licensing export.csv n'affiche pas les données de la région.

• Problème 38843 :

  Lors du transfert d'un mappage d'application, il n'y a pas d'événement d'opérateur et l'événement de dispositif Edge est d'utilité limitée.

• Problème 39633 :

  Le lien hypertexte de la super passerelle ne fonctionne pas lorsqu'un utilisateur attribue la passerelle secondaire comme super passerelle.

• Problème 39790 :

  VMware SD-WAN Orchestrator permet à un utilisateur de configurer une interface routée d'un dispositif VMware SD-WAN Edge sur une valeur supérieure aux 32 sous-interfaces prises en charge, ce qui crée le risque qu'un utilisateur puisse configurer 33 sous-interfaces ou plus sur une interface, ce qui entraîne l'échec du service de plan de données pour le dispositif Edge.

• Problème 41691 :

  L'utilisateur ne peut pas modifier le champ Nombre d'adresses (Number of addresses), bien que le pool DHCP ne soit pas épuisé sur la page Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device).

• Problème 43276 :

  L'utilisateur ne peut pas modifier le type de segment lorsqu'une passerelle partenaire est configurée pour un dispositif ou un profil VMware SD-WAN Edge.

  Solution : Supprimez temporairement la configuration de la passerelle partenaire du profil ou du dispositif Edge afin de modifier le segment entre privé et standard. L'utilisateur peut également supprimer le segment du profil et effectuer la modification à partir de cet emplacement.

• Problème 47713 :

   Si une règle de Business Policy est configurée alors que le VPN cloud est désactivé, la configuration NAT doit être reconfigurée lors de l'activation du VPN cloud.

• Problème 47820 :

  Si la configuration de VLAN prévoit la désactivation de DHCP au niveau du profil, tout en ayant prévoyant également un remplacement Edge pour ce VLAN sur ce dispositif Edge, alors que DHCP est activé et qu'une entrée pour le champ Serveur DNS est définie sur Aucun (None) (aucune adresse IP n'est configurée), l'utilisateur ne peut pas modifier la page Configurer (Configure) > Dispositif Edge (Edge) > Dispositif (Device) et obtient le message d'erreur « Adresse IP non valide [] » (invalid IP address []) qui n'identifie pas le problème réel et ne l'explique pas.

• Problème 48085 : VMware SD-WAN Orchestrator permet à un utilisateur de supprimer un VLAN associé à une interface.

  Lorsque ce problème se produit, un message d'erreur semblable à « VLAN ID [xx] cannot be removed, in use by edge [b1-edge1 (GEx-disabled] » s'affiche.

• Problème 51722 : Sur VMware SASE Orchestrator, le sélecteur de plage de temps n'est pas supérieur à deux semaines pour les statistiques dans les onglets Surveiller (Monitor) > Dispositif Edge (Edge).

  Le sélecteur de plage de temps n'affiche pas les options supérieures à « 2 dernières semaines » (Past 2 Weeks) dans les onglets Surveiller (Monitor) > Dispositif Edge (Edge), même si la période de rétention d'un ensemble de statistiques est bien supérieure à 2 semaines. Par exemple, les statistiques de flux et de liens sont conservées par défaut pendant 365 jours (ce qui est configurable), tandis que les statistiques de chemins ne sont conservées que pendant 2 semaines par défaut (également configurable). Ce problème consiste à faire en sorte que tous les onglets de Surveiller (Monitor) soient conformes au type de statistique le plus faible conservé et à permettre à un utilisateur de sélectionner une période cohérente avec la période de rétention de cette statistique.

  Solution : Un utilisateur peut utiliser l'option « Personnalisé » (Custom) dans le sélecteur de plage de temps pour consulter les données pendant plus de 2 semaines.

• Problème 60522 : Dans l'interface utilisateur de VMware SD-WAN Orchestrator, l'utilisateur observe un grand nombre de messages d'erreur lorsqu'il tente de supprimer un segment.

  Ce problème peut s'observer lors de l'ajout d'un segment à un profil et de l'association du segment à plusieurs dispositifs VMware SD-WAN Edge. Lorsque l'utilisateur tente de supprimer le segment ajouté du profil, plusieurs messages d'erreur s'affichent.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 82095 : L'utilisateur peut configurer des paramètres de périphériques non valides pour les VLAN Edge qui entraînent un problème de connectivité pour le dispositif Edge.

  Orchestrator ne tente pas de valider les configurations des périphériques. En particulier, une configuration VLAN pour un port commuté avec une table vide. Certaines configurations peuvent comporter tellement d'erreurs que le processus de gestion du dispositif Edge échoue.

  Solution : Examinez tous les paramètres du périphérique VLAN et assurez-vous qu'ils sont valides, car Orchestrator ne les vérifie pas.

• Problème 82680 : Pour un client utilisant l'automatisation du tunnel MT-GRE, lorsqu'un utilisateur désactive l'indicateur d'interconnexion entre deux clouds (CCI, Cloud-to-Cloud Interconnect) sur une passerelle VMware SD-WAN Gateway configurée pour utiliser la CCI, les entrées MT-GRE de Zscaler peuvent ne pas être supprimées du portail Zscaler de façon cohérente.

  La suppression d'un site CCI de la passerelle entraîne celle des entrées de ce site. Ce problème n'a été observé que lors de l'automatisation de test et n'a pas été reproduit manuellement, mais représente toujours un risque.

  Solution : Supprimez manuellement la ressource de Zscaler avant de réessayer.

• Problème 82681 : Pour un client utilisant l'automatisation du tunnel MT-GRE, lorsqu'un utilisateur désactive l'indicateur d'interconnexion entre deux clouds (CCI) sur une passerelle VMware SD-WAN Gateway configurée pour utiliser la CCI, et que l'utilisateur désactive l'indicateur CCI d'un dispositif VMware SD-WAN Edge avec une CCI configurée qui utilise un service de sécurité cloud Zscaler, les entrées MT-GRE de Zscaler peuvent ne pas être supprimées du dispositif Edge ou du portail Zscaler.

  La suppression d'un site CCI de la passerelle entraîne celle des entrées de ce site. Ce problème n'a été observé que lors de l'automatisation de test et n'a pas été reproduit manuellement, mais représente toujours un risque.

  Solution : Supprimez manuellement la ressource de Zscaler avant de réessayer.

• Problème 103769 : Un opérateur peut observer qu'un dispositif VMware SASE Orchestrator dans un déploiement à grande échelle rencontre des problèmes de performances qui incluent une utilisation du disque à 100 % et qu'Orchestrator n'accumule plus les journaux.

  Ce problème survient lors d'une modification du comportement de journalisation d'Orchestrator 5.1.0, ce qui peut entraîner l'utilisation à 100 % des dossiers qui stockent les journaux, ainsi qu'une utilisation de 100 % du CPU d'Orchestrator. Ce problème survient lors d'une modification du comportement de journalisation d'Orchestrator 5.1.0, ce qui peut entraîner l'utilisation à 100 % des dossiers qui stockent les journaux, ainsi qu'une utilisation de 100 % du CPU d'Orchestrator.

  Solution : Un super utilisateur opérateur doit se connecter à Orchestrator et nettoyer les journaux en attente.

• Problème 117699 : Il se peut qu'un opérateur tentant de mettre à niveau un dispositif VMware SD-WAN Orchestrator 4.2.x vers SASE Orchestrator 5.2.0 observe l'échec de la mise à niveau.

  La mise à niveau échoue et est effectivement bloquée à l'étape « En attente de l'activation du service CWS… » (Waiting for the CWS service up). Ce problème est limité aux dispositifs Orchestrator version 4.2.x.

  Solution : La solution à ce problème consiste à mettre d'abord à niveau Orchestrator 4.2.x vers la version 4.5.1, puis vers la version 5.2.0.0.

• Problème 118501 : sur la page Surveiller (Monitor) > Dispositifs Edge (Edges), si un utilisateur clique sur CSV pour télécharger sa liste de tous les dispositifs SD-WAN Edge, Orchestrator ne télécharge que 2 048 dispositifs Edge au maximum.

  Ce problème affecte les clients qui possèdent plus de 2 048 dispositifs Edge dans leur entreprise et qui doivent télécharger une liste complète de tous leurs dispositifs Edge.

  Solution : la seule solution consiste à diviser le téléchargement en deux parties ou plus en triant les dispositifs Edge.

• Problème 122193 : sur la page Configurer (Configure) > Dispositifs Edge (Edges) > Pare-feu (Firewall), lors de la configuration d'une règle de pare-feu pour un dispositif Edge, un utilisateur peut uniquement sélectionner Autoriser (Allow) comme Action de pare-feu (Firewall Action).

  Lorsque l'utilisateur clique sur Action de pare-feu (Firewall Action), le menu déroulant s'affiche pendant une fraction de seconde et disparaît immédiatement, et l'utilisateur ne peut pas remplacer l'option par défaut Autoriser (Allow) par une autre option.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 125082 : si un utilisateur configure un dispositif VMware SD-WAN Edge avec une adresse IP de serveur DNS remplacée sur un VLAN, puis modifie un paramètre d'interface du profil utilisé par le dispositif Edge, l'adresse IP du serveur DNS n'est plus présente pour le VLAN du dispositif Edge.

  L'interface utilisateur n'envoie pas l'indicateur de remplacement à l'intérieur de la section DHCP, ce qui entraîne le déclenchement d'un remplacement de la section DHCP en cas de modification du profil.

  Solution : Après une modification du profil, l'utilisateur doit passer en revue et corriger les options DHCP remplacées sur des dispositifs Edge individuels.

• Problème 125504 : si une route statique est configurée avec un next-hop en tant que VLAN avec une adresse IPv4/IPv6 au niveau du profil, est remplacée au niveau du dispositif Edge, puis qu'une adresse IPv4/IPv6 est ajoutée au VLAN, la route statique ne porte pas la mention S/O et l'instance de VMware SASE Orchestrator demande l'interface dans un menu déroulant.

  Le comportement attendu est le suivant : lorsqu'une route statique est configurée avec un next-hop en tant que VLAN avec une adresse IPv4/IPv6, Orchestrator ne demande pas l'interface et la route porte la mention S/O.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 125663 : un utilisateur peut configurer la même adresse IP IPv4/IPv6 pour plusieurs interfaces Edge.

  VMware SASE Orchestrator permet à un utilisateur de configurer la même adresse IP sur plusieurs WAN, LAN ou sous-interfaces.

  Solution : À part vous assurer de ne pas configurer la même adresse IP pour plusieurs interfaces, il n'existe aucune solution à ce problème.

• Problème 126421 : pour les partenaires utilisant une passerelle de partenaire, lors de la configuration des détails du transfert, la case Utiliser pour les tunnels privés (Use for Private Tunnels) est toujours cochée, peu importe ce que fait l'utilisateur.

  Il ne s'agit pas d'un problème superficiel, car Orchestrator applique la configuration Utiliser pour les tunnels privés (Use for Private Tunnels) au transfert de la passerelle partenaire, ce qui peut avoir une incidence sur le trafic client utilisant la passerelle de partenaire.

  Solution : Il n'existe aucune solution à ce problème sur un dispositif Orchestrator disposant uniquement de la nouvelle interface utilisateur.

• Problème 126425 : sur la page Configurer (Configure) > Périphérique (Device) > Routage et NAT (Routing & NAT) au niveau du profil, le bouton bascule permettant d'activer ou de désactiver OSPF est manquant.

  Le bouton bascule permettant d'activer ou de désactiver OSPF n'a pas été migré vers la nouvelle interface utilisateur au niveau du profil et ne figure qu'au niveau du dispositif Edge.

  Solution : Il n'existe aucune solution à ce problème sur un dispositif Orchestrator disposant uniquement de la nouvelle interface utilisateur.

• Problème 126465 : l'interface utilisateur de VMware SASE Orchestrator n'applique pas les modifications apportées par un utilisateur pour créer un cluster Edge.

  Si un utilisateur accède à la section Configurer (Configure) > Dispositif Edge (Edge) > Haute disponibilité (High Availability) de l'interface utilisateur, active HA avec un type de cluster, crée un cluster Hub avec le nom xxxx et enregistre les modifications, il constate après l'enregistrement que l'option Cluster n'est pas sélectionnée sous la section HA et que le cluster Hub créé avec le nom xxxx est absent.

  Solution : Il n'existe aucune solution à ce problème sur un dispositif Orchestrator disposant uniquement de la nouvelle interface utilisateur.

• Problème 127152 : les utilisateurs ne peuvent pas enregistrer les interfaces modifiées avec des configurations OSPF dans l'interface utilisateur de VMware SASE Orchestrator.

  Au niveau du profil, lors de la configuration d'OSPFv2/OSPFv3, la boîte de dialogue Modifier l'interface (Edit Interface) devient non valide après la modification des données OSPF.

  Solution : Sur un dispositif Orchestrator sans correctif pour ce problème, un utilisateur doit activer l'authentification MD5 et remplacer l'ID de clé par un nombre compris entre 1 et 255, puis désactiver l'authentification MD5.

• Problème 128070 : lorsqu'un utilisateur configure OSPFv3 pour un VLAN au niveau du dispositif Edge et tente d'ajouter des paramètres IPv6 au VLAN, l'interface utilisateur de VMware SASE Orchestrator n'enregistre pas les modifications.

  L'option Enregistrer est grisée et n'est pas disponible lorsque vous tentez d'ajouter des paramètres IPv6 à un VLAN avec OSPF3 au niveau du dispositif Edge.

  Solution : Il n'existe aucune solution à ce problème sur un dispositif Orchestrator disposant uniquement de la nouvelle interface utilisateur.

• Problème 129232 : un utilisateur ne peut pas effectuer une réinitialisation automatique du mot de passe sur l'instance VMware SASE Orchestrator.

  Lorsque l'utilisateur tente d'accéder au lien de réinitialisation automatique du mot de passe directement dans le navigateur, il est redirigé vers la page de connexion au lieu de la page de réinitialisation du mot de passe.

  Solution : un utilisateur qui doit réinitialiser son mot de passe doit contacter un super utilisateur d'entreprise dans son organisation, un administrateur partenaire (le cas échéant) ou le support VMware SD-WAN pour réinitialiser son mot de passe.

• Problème 129412 : sur la page Configurer (Configure) > Edge > Périphérique (Device) > Connectivité (Connectivity) > VLAN de l'interface utilisateur, dans la section Serveur DHCP IPv4 (IPv4 DHCP Server), le nombre d'adresses affiché peut être inexact.

  Ce comportement se produit lorsqu'un utilisateur modifie la valeur DHCP d'origine pour augmenter le nombre d'adresses. L'interface utilisateur continue alors d'afficher le nombre inférieur d'adresses plus ancien.

  Solution : il s'agit d'un problème superficiel. La valeur DHCP réelle est appliquée.

• Problème 129662 : un utilisateur ne peut pas déterminer si une interface VMware SD-WAN est activée ou désactivée lorsqu'il consulte la page Configurer (Configure) > Edge > Périphérique (Device) > Interfaces de l'interface utilisateur d'Orchestrator.

  L'interface utilisateur de VMware SASE Orchestrator ne différencie pas les interfaces activées et désactivées au moyen de couleurs différentes, ce qui empêche les clients d'identifier une sous-interface désactivée.

  Solution : Il n'existe aucune solution à ce problème.

• Problème 129958 : sur la page Configurer (Configure) > Edge > Périphérique (Device) > Connectivité (Connectivity) > VLAN de l'interface utilisateur, dans la section Serveur DHCP IPv4 (IPv4 DHCP Server), l'utilisateur ne peut pas modifier le nombre d'adresses, à moins de remplacer d'abord le VLAN général.

  Auparavant, un utilisateur pouvait remplacer une sous-section d'un VLAN Edge, comme DHCP ou OSPF, tout en acceptant le reste de la configuration du profil. Dans cette instance, l'utilisateur doit remplacer l'intégralité du VLAN pour pouvoir modifier la partie DHCP de celui-ci.

  Solution : un utilisateur peut uniquement remplacer l'intégralité du VLAN pour en modifier les paramètres.

• Problème 131299 : sur la page Configurer (Configure) > Overlay Flow Control de l'interface utilisateur, lorsque l'utilisateur modifie le segment d'une destination non-SD-WAN via une passerelle qui utilise des routes statiques, le tableau OFC n'affiche pas les routes statiques mises à jour.

  Au lieu de cela, le tableau OFC affiche les résultats en utilisant le segment sélectionné précédemment, ce qui amène l'utilisateur à penser à tort que la modification qu'il a apportée à la configuration n'a pas été appliquée.

  Solution : il n'existe pas de solution, mais ce problème est superficiel et les routes statiques sont bien remplacées par le nouveau segment.

• Problème 131997 : une sonde ICMP peut être marquée par erreur comme inactive lorsqu'elle est configurée pour un segment, mais pas pour un autre.

  Orchestrator ne parvient pas à envoyer la configuration de la sonde ICMP NULL lorsqu'elle n'est pas configurée dans un segment. Par conséquent, la configuration d'un segment différent est réutilisée, ce qui entraîne l'échec des sondes.

  Solution : Sur une instance d'Orchestrator sans correctif pour ce problème, configurez une sonde ICMP factice pour les autres segments.

• Problème 133201 : sur la page Paramètres globaux (Global Settings) > Gestion des utilisateurs (User Management) de l'interface utilisateur d'Orchestrator, si un utilisateur crée ou modifie un rôle personnalisé et tente de modifier le paramètre Supprimer (Delete) pour les privilèges du bundle PCAP, l'interface utilisateur modifie également tous les autres paramètres du bundle PCAP.

  Par exemple, si un utilisateur choisit de désactiver le bundle PCAP Suppression (Deletion), l'interface utilisateur désactive également les paramètres Lire (Read), Mettre à jour (Update) et Créer (Create), même si l'utilisateur souhaite que ces paramètres restent activés.

  Solution : un utilisateur doit tenir compte des modifications apportées et restaurer les paramètres Lire (Read), Mettre à jour (Update) et Créer (Create) si nécessaire.

• Problème 133642 : sur la page Configurer (Configure) > Edge > Périphérique (Device) > Connectivité (Connectivity) > VLAN de l'interface utilisateur, le VLAN du dispositif Edge est automatiquement défini sur Remplacer (Override) par défaut et un utilisateur ne peut pas désactiver ce paramètre.

  Le comportement attendu est que si un utilisateur crée un VLAN au niveau du profil, le paramètre Remplacement du dispositif Edge (Edge Override) est désactivé par défaut et l'utilisateur doit choisir d'activer Remplacement du dispositif Edge (Edge Override) pour chaque dispositif Edge.

  Solution : il n'existe aucune solution autre que l'inspection de chaque dispositif Edge utilisant ce profil et la désactivation de Remplacement du dispositif Edge (Edge Override) si nécessaire.