Notes de mise à jour de VMware SASE 5.4.0

VMware SASE 5.4.0 | 16 novembre 2023 VMware SASE™ Orchestrator version R5401-20231115-GA VMware SD-WAN™ Gateway version R5400-20231009-GA VMware SD-WAN™ Edge version R5400-20231108-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 et améliorations de SASE
• Nouvelles fonctionnalités et 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.4.0.

Important:

La version 5.4.0 contient tous les correctifs d'Edge et de Gateway répertoriés dans les Notes de mise à jour de la version 5.2.0 jusqu'à la version 5.2.0.2, ainsi que tous les correctifs d'Orchestrator répertoriés dans les Notes de mise à jour de la version 5.2.0 jusqu'à la version 5.2.0.3 et dans les Notes de mise à jour de la version 5.3.0 jusqu'à la version 5.3.0.2.

Compatibilité

Les instances d'Orchestrator, les passerelles Gateway et les dispositifs Edge du Hub de la version 5.4.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.4.0	4.2.2	4.2.2	4.2.2
5.4.0	5.4.0	4.2.2	4.2.2
5.4.0	5.4.0	5.4.0	4.2.2
5.4.0	5.4.0	4.2.2	5.4.0
5.4.0	4.3.2	4.3.2	4.3.2
5.4.0	5.4.0	4.3.2	4.3.2
5.4.0	5.4.0	5.4.0	4.3.2
5.4.0	5.4.0	4.3.2	5.4.0
5.4.0	4.5.2	4.5.2	4.5.2
5.4.0	5.4.0	4.5.2	4.5.2
5.4.0	5.4.0	5.4.0	4.5.2
5.4.0	5.4.0	4.5.2	5.4.0
5.4.0	5.0.1.3	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.4.0	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.4.0
5.4.0	5.1.0.3	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.4.0	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.4.0
5.4.0	5.2.0.1	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.4.0	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.4.0
5.4.0	5.4.0	5.4.0	5.4.0

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 vers la version 5.4.0 à partir d'une version antérieure.

Orchestrator

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

Gateway

La mise à niveau d'une passerelle Gateway utilisant la version 4.3.0 ou une version ultérieure vers la version 5.4.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.4.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.4.0 ou ultérieure.

Important:

Avant la mise à niveau d'une passerelle Gateway vers la version 5.4.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.4.0 ou ultérieure.

Dispositif Edge

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

Nouvelles fonctionnalités et améliorations de SASE

Dispositif Orchestrator de bastion, phase 2

Présenté pour la première fois dans la version 4.3.0, VMware SASE apporte des améliorations majeures au dispositif Orchestrator de bastion dans la version 5.4.0. Les améliorations de la phase 2 incluent :

• Mise à jour logicielle du dispositif SD-WAN Edge lorsque celui-ci est à l'état activé.

• Restauration de la dernière configuration correcte connue en cas d'échec de la promotion du dispositif Edge.

• Les événements d'un dispositif Edge non promu sont envoyés à un dispositif VMware SASE Orchestrator privé.

• Génération d'un bundle de diagnostics pour un dispositif Edge non promu.

• Mises à jour du microprogramme d'entreprise sur le dispositif VMware SASE Orchestrator de bastion.

SD-WAN Client intégré au dispositif VMware SASE Orchestrator

VMware SD-WAN Client peut désormais être géré via VMware SASE Orchestrator, fournissant ainsi une console de gestion unifiée pour la gestion des solutions de mise en réseau, de sécurité et d'accès à distance.

Nouvelles fonctionnalités et améliorations de SD-WAN

Prise en charge du pare-feu Edge pour FTPv6

La version 5.4.0 inclut une identification d'application améliorée pour les modes Actif (Active) et Passif (Passive) de FTPv4/FTPv6 lors de l'utilisation de l'inspection approfondie des paquets (DPI) de VMware SD-WAN. Cette DPI améliorée est particulièrement utile pour les clients qui utilisent le mode FTPv6 passif, qui attribue des numéros de port aléatoires pour le transfert de données et rend le trafic FTP difficile à identifier, car il n'utilise pas les ports standard 20 et 21.

Améliorations de l'affichage et de la recherche du service de pare-feu amélioré

Le Service de pare-feu amélioré (Enhanced Firewall Service) inclut désormais une vue de tableau de pare-feu avec un champ Commentaires (Comments) et une nouvelle capacité de recherche de règles et d'objets de pare-feu afin de fournir une expérience utilisateur optimale.

Vue de signature du service de pare-feu amélioré (IDS/IPS)

Ce service inclut une vue de signature améliorée (IDS/IPS), qui fournit une vue simplifiée avec une visibilité des signatures de systèmes de détection des intrusions (IDS) et de systèmes de prévention des intrusions (IPS) installées sur un dispositif VMware SD-WAN Edge, ainsi que la version et les données installées, et l'heure de l'installation.

Améliorations de la haute disponibilité, phase 2

La version 5.4.0 inclut des améliorations supplémentaires 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 :

• Alertes (Alerts) : Une nouvelle alerte est ajoutée à la liste sur la page Paramètres de service (Service Settings) > Alertes et notifications (Alerts & Notifications), Échec du dispositif Edge HA (Edge HA Failed). L'alerte Échec du dispositif Edge HA (Edge HA Failed) est déclenchée lorsque le dispositif Edge passif ne parvient pas à émettre un signal de pulsation au dispositif Edge actif et qu'il est marqué comme étant inactif par le dispositif Edge actif. Cette alerte est particulièrement utile dans les déploiements HA améliorée dans lesquels le dispositif Edge passif transmet également le trafic client.

• Compatibilité entre les dispositifs Edge compatibles Wi-Fi et non compatibles Wi-Fi (Compatibility between Wi-Fi and Non Wi-Fi Capable Edges) : Avant la version 5.4.0 d'Edge, les modèles d'Edge qui n'incluaient pas de module Wi-Fi (510N, 610N, 620N, 640N et 680N) ne pouvaient pas être utilisés avec un homologue compatible Wi-Fi dans un déploiement HA. Par exemple, un dispositif Edge 640 et un dispositif Edge 640N n'étaient pas pris en charge comme paire haute disponibilité. Pour la version 5.4.0 et les versions ultérieures, ce couplage est désormais pris en charge.

Note:

Dans un scénario comportant des dispositifs Edge Wi-Fi et non compatibles Wi-Fi qui ne correspondent pas, Orchestrator détecte l'incompatibilité des dispositifs Edge et désactive automatiquement la fonctionnalité Wi-Fi sur le dispositif Edge compatible Wi-Fi. Le journal d'incompatibilité s'affiche dans Événements (Events) du client :

• Incompatibilité de fonctionnalité Wi-Fi HA identifiée, Wi-Fi désactivé (HA Wi-Fi capability mismatch identified, disabled Wi-Fi) (une incompatibilité Wi-Fi du dispositif Edge est identifiée et le Wi-Fi est désactivé sur le dispositif Edge compatible Wi-Fi).

• Incompatibilité de fonctionnalité Wi-Fi HA n'étant plus détectée, Wi-Fi rétabli (HA Wi-Fi capability mismatch no longer seen, reverted Wi-Fi) (les deux dispositifs Edge sont détectés comme le même type de Wi-Fi et la fonctionnalité Wi-Fi est restaurée sur un dispositif Edge Wi-Fi sur lequel elle était précédemment désactivée).

Interconnexion du Hub ou du cluster étant GA

Présentée pour la première fois comme fonctionnalité d'accès en avant-première dans SD-WAN version 5.1.0, Interconnexion du Hub ou du cluster (Hub or Cluster Interconnect) est entièrement GA dans la version 5.4.0. Cette solution permet aux clients de créer une architecture hiérarchique et évolutive avec une connectivité d'overlay SD-WAN complète sur les Hubs de cloud, régionaux et de centre de données, ce qui fournit une protection DMPO (optimisation dynamique des chemins multiples) complète, une visibilité de bout en bout et une fiabilité.

En plus de la prise en charge complète de cette fonctionnalité, la restriction précédente du nombre de hops de 2 est passée à un nombre éligible de quatre hops.

Délégation de préfixe DHCPv6 IPv6

La version 5.4.0 ajoute la prise en charge de la délégation de préfixe DHCPv6 pour les clients pour lesquels leur routeur délégant fait partie de l'hébergement cloud ou se trouve à un emplacement distant, ou dans des scénarios dans lesquels l'ISP du client alloue des adresses IP. La délégation de préfixe DHCPv6 inclut de nouveaux types d'adresses pour IPv6 et prend en charge deux serveurs de délégation de préfixes ISP pour autoriser une topologie principale et de sauvegarde.

Important:

Pour utiliser la fonctionnalité de délégation de préfixe, Orchestrator, Gateway et Edge doivent tous utiliser une version logicielle 5.4.0 ou une version ultérieure. La délégation de préfixe n'est pas compatible sur un dispositif Edge utilisant la version 5.2.0 ou une version antérieure. Si un dispositif Edge utilisant la version 5.2.0 ou une version antérieure est configuré pour la délégation de préfixe, la fonctionnalité ne fonctionne pas comme prévu.

En outre, un dispositif Edge utilisant la version 5.2.0 ou une version antérieure configuré avec la délégation de préfixe ne peut pas être mis à niveau vers la version 5.4.0. Par conséquent, si vous mettez à niveau un dispositif Edge 5.2.0 ou une version antérieure vers la version 5.4.0 ou une version ultérieure, assurez-vous que la délégation de préfixe n'est pas utilisée sur ce dispositif Edge.

Prise en charge des pilotes bifurqués Mellanox pour le dispositif Edge virtuel Microsoft Azure

VMware SD-WAN prend en charge la mise en réseau accélérée (SR-IOV) pour le dispositif Edge virtuel Microsoft Azure et inclut la prise en charge des cartes réseau Mellanox ConnectX-4 et ConnectX-5. Lors de l'activation de SR-IOV sur une interface du dispositif Edge virtuel Azure, l'amélioration est automatiquement activée sur le dispositif Edge.​

La mise en réseau accélérée peut être activée ou désactivée via le portail Azure, l'interface de ligne de commande Azure ou Azure PowerShell.​

Note:

Cette amélioration n'inclut pas la prise en charge des cartes réseau Mellanox ConnectX-3

Chemin rapide de l'exécution jusqu'à l'achèvement sur le dispositif Edge, phase 3

L'exécution jusqu'à l'achèvement est une optimisation logicielle qui augmente les performances sur les dispositifs Edge et les passerelles, ce qui entraîne une amélioration de l'efficacité globale de la solution SD-WAN.

Remarques importantes

Modification du comportement de la NAT côté LAN

À partir de la version 4.5 et des versions ultérieures, 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 jusqu'à la version 5.2.0, 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.

À partir de la version 5.4.0, un utilisateur peut trouver six compteurs distincts dans les journaux :

• lan_side_nat_rev_pat_drop_snat1

• lan_side_nat_rev_pat_drop_snat2

• lan_side_nat_rev_pat_drop_dnat1

• lan_side_nat_rev_pat_drop_dnat2

• lan_side_nat_rev_pat_drop_sdnat1

• lan_side_nat_rev_pat_drop_sdnat2

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

VMware SASE Orchestrator utilisant la version 5.4.0 est localisé 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 apportées à l'API Orchestrator depuis la version 5.3.0

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

Les problèmes suivants ont une incidence sur les utilisateurs de l'API v1 :

Ticket	Symptôme/Description
Problème connu n °118684	APIv1 n'inclut pas les ID incrémentiels dans la charge utile pour la référence utilisateur. Dans le cadre de la migration en cours vers un nouveau système de gestion de base de données, VMware SD-WAN a remplacé certains ID incrémentiels, tels que edgeId, par des ID logiques. Cette modification est nécessaire, car la plupart des interfaces utilisent désormais des ID logiques. Il s'agit d'un problème purement superficiel, et vous pouvez mapper en toute sécurité l'ID edgeId appelant à l'ID edgeLogicalId qui effectue le renvoi.
Problème connu n °123867	Les mesures de lien et les API de série renvoient une erreur lorsqu'elles sont appelées sans liste de mesures. Ce problème sera corrigé dans une version ultérieure. Pour résoudre ce problème, vous pouvez envoyer votre demande d'API avec une liste des champs de mesures que vous souhaitez renvoyer. Cela garantit que vous recevez les données dont vous avez besoin, même si l'API renvoie un message d'erreur. Ce problème n'affecte pas la fonctionnalité des API, vous pouvez donc toujours les utiliser pour récupérer des données.
Problème connu n °127994	La spécification Swagger signale une erreur de schéma en raison d'une propriété additionalProperty: title dans le schéma de réponse. Il s'agit d'un problème superficiel qui n'affecte pas la fonctionnalité de l'API. Ce problème sera résolu dans une version ultérieure et l'API pourra toujours être utilisée pour récupérer des données, même si Orchestrator reçoit cette erreur de schéma.
Problème résolu n °127995	La spécification Swagger signale une erreur de schéma en raison d'un type incorrect dans le champ Éléments (Items) du schéma de réponse. Il s'agit d'un problème superficiel qui n'affecte pas la capacité de l'API à récupérer des données. L'erreur peut être alors ignorée sans risque. Ce problème est résolu dans la version 5.4.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

Il n'existe aucune nouvelle API v2 depuis la version 5.3.0.

Les modifications suivantes sont apportées dans l'API v2 de la version 5.3.0 vers la version 5.4.0.

Ticket	Symptôme/Description
Problème résolu n °116610	Les utilisateurs ne peuvent pas ajouter une nouvelle interface Loopback via APIv2. La structure de schéma de l'interface Loopback dans APIv2 n'autorisait pas les interfaces nommées par l'ID d'interface. Par conséquent, la mise à jour de l'interface Loopback échoue.
Problème résolu n °129679	Les clients ne pourront pas mettre à jour le module des paramètres du périphérique du dispositif Edge à l'aide des paramètres du périphérique Edge PATCH APIv2 lorsque des sous-interfaces sont configurées sur le module des paramètres du périphérique du dispositif Edge. Lorsque des sous-interfaces sont configurées sur le module des paramètres du périphérique du dispositif Edge, un appel d'API à l'API des paramètres du périphérique Edge PATCH v2 entraîne l'attente de la demande dans un état Accepté (Accepted) permanent et finit par expirer. Par conséquent, les clients ne verront aucune modification appliquée dans le module des paramètres du périphérique Edge sur Orchestrator.

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

16 novembre 2023. Deuxième édition.

• Ajout d'une nouvelle build cumulative R5401-20231115-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.4.0.

• La build R5401-20231115-GA d'Orchestrator inclut les correctifs des problèmes n °117138, n °123078, n °123387, n °125309, n °125964, n °126602, n °127727, n °127774, n °127843, n °127904, n °128017, n °128277, n °128279, n °128357, n °128765, n °129061, n °129494, n °129584, n °129756, n °129765, n °129894, n °130153, n °130877 et n °131846, qui sont documentés dans cette section.

• Ajout de la build R5400-20231108-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 build GA R5400-20231009-GA d'Edge initiale. Elle constitue la nouvelle build GA d'Edge/de Gateway par défaut pour la version 5.4.0.

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

  Important:

  • La build précédente d'Edge de la version 5.4.0 est déconseillée en faveur de R5400-20231108-GA-125647.

  • Les clients effectuant une mise à niveau vers la version 5.4.0 doivent uniquement effectuer une mise à niveau vers R5202-20231107-GA-125647.

  • Les clients qui utilisent déjà la build d'Edge initiale de la version 5.4.0 n'ont pas besoin de mettre à niveau leurs dispositifs Edge vers R5400-20231108-GA-125647.

19 octobre 2023. Première édition.

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

• Résolu dans Edge version R5400-20231108-GA-125647
• Résolu dans Edge et Gateway version R5400-20231009-GA

Résolu dans Edge version R5400-20231108-GA-125647

La build R5400-20231108-GA-125647 d'Edge a été publiée le 14/11/2023 et constitue une mise à jour de la build GA d'Edge pour la version 5.4.0.

Cette build d'Edge mise à jour résout le problème critique ci-dessous depuis la build GA initiale, R5400-20231009-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 Edge et Gateway version R5400-20231009-GA

La build R5400-20231009-GA d'Edge et de Gateway a été publiée le 23/10/2023 et résout les problèmes suivants depuis la build R5202-20230725-GA d'Edge et de Gateway.

Note:

La version 5.4.0 contient tous les correctifs d'Edge et de Gateway documentés dans les Notes de mise à jour de la version 5.2.0 jusqu'à la version 5.2.0.2 (R5202-20230725-GA).

• Problème résolu 69641 : Pour une entreprise cliente qui utilise une ou plusieurs business policies qui incluent des limites de débit, le client peut observer des abandons de paquets sur tous les flux, même ceux qui ne sont pas liés aux flux de business policy avec limites de débit et sur d'autres segments et peers.

  La définition d'une business policy avec limites de débit et l'envoi d'un trafic de demande plus élevé (supérieur à la limite) avec un nombre élevé de flux entraînent l'abandon de paquets provenant d'autres flux (même d'autres segments et peers) en raison du dépassement de la limite de tampon du planificateur réseau.

  Dans une entreprise dont les dispositifs Edge ne disposent pas d'un correctif pour ce problème, la solution consiste à supprimer la configuration de la limite de débit et à reclasser plutôt le trafic correspondant à la règle avec la valeur la plus faible possible [Faible, En bloc (Low, Bulk)].

• Problème résolu 74422 : En cas de haute disponibilité, le dispositif Edge peut passer hors ligne si seul le dispositif Edge en veille dispose d'un lien WAN actif et d'une adresse IP valide.

  Ce problème se produit lorsqu'un protocole DHCP est activé sur un lien WAN alors que seul le dispositif Edge en veille dispose d'un lien WAN disponible. Lorsque le lien WAN en veille reçoit une adresse IP du serveur DHCP, il envoie les détails de l'interface au dispositif Edge actif. Le dispositif Edge actif effectue un appel pour ajouter l'adresse IP en tant que route, mais cette fonction n'ajoute pas la route au noyau Linux. La fonction Edge ajoute uniquement la route à la base d'informations de transfert (FIB, Forwarding Information Base). Par conséquent, le processus de gestion du dispositif Edge renvoie une erreur, car aucune route n'est présente dans la table de routage du noyau Linux pour permettre la sortie du paquet et le site est effectivement hors ligne.

• Problème résolu 79598 : Pour une entreprise cliente utilisant Zscaler avec des tunnels redondants, lors d'un basculement du tunnel principal vers le tunnel secondaire, le trafic revient vers le tunnel principal plus tôt que prévu.

  Le comportement attendu est que le tunnel Zscaler principal s'active et que le trafic continue à utiliser le tunnel secondaire pendant 30 minutes avant que le trafic ne soit redirigé vers le tunnel principal. Cela garantit que le tunnel principal est stable et moins susceptible de s'arrêter à nouveau, forçant un autre basculement du trafic. Avec ce problème, le trafic est dirigé vers le tunnel principal en moins de 30 minutes.

• Problème résolu 91164 : Un Hub Edge avec la haute disponibilité configurée peut ne pas transférer le trafic de backhaul Internet après un basculement HA.

  Le dispositif Edge en veille ne définit pas la route de destination pour les flux de backhaul Internet lorsque le flux de backhaul est configuré pour l'acheminement via une route statique à l'aide d'une interface routée pour laquelle l'overlay WAN est activé.

• Problème résolu 92421 : Lorsqu'un overlay public et privé est configuré sur la même interface Edge avec différentes balises VLAN personnalisées, il est possible que le trafic routé de l'underlay soit abandonné.

  Lorsqu'un overlay public et privé est configuré sur la même interface avec différentes balises VLAN personnalisées, le dispositif Edge peut apprendre les entrées ARP avec les balises VLAN incorrectes, ce qui entraîne l'abandon du trafic.

• Problème résolu 96334 : Sur une instance de VMware SASE Orchestrator où l'adresse IP change fréquemment, les dispositifs VMware SD-WAN Edge peuvent perdre contact avec Orchestrator et être signalés comme étant hors ligne.

  Dans ce scénario où l'adresse IP d'Orchestrator change fréquemment, les dispositifs Edge répondent à chaque changement d'adresse IP d'Orchestrator en modifiant la source du trafic de gestion d'une interface Loopback à l'adresse IP du port GE1, même lorsqu'Orchestrator est configuré pour utiliser exclusivement l'interface Loopback en tant que source. Par conséquent, les dispositifs Edge perdent le contact avec Orchestrator et, bien que cela n'ait pas d'incidence sur le trafic client, ce problème empêche les mises à jour de la configuration et la surveillance de fonctionner comme prévu.

• Problème résolu 99162 : Si un dispositif VMware SD-WAN Edge présente de fréquents bagotements de tunnel, cela peut entraîner une augmentation de la consommation de mémoire et éventuellement entraîner un redémarrage défensif du dispositif Edge pour récupérer la mémoire.

  La mémoire du dispositif Edge affectée est l'objet vc_edge_route, que le service Edge n'efface pas après le démontage, puis la recréation de chaque instance d'un tunnel. Comme toute fuite de mémoire, si une quantité suffisante de mémoire Edge est consommée par cette fuite, le dispositif Edge déclenche un redémarrage du service pour effacer la mémoire, ce qui peut perturber le trafic utilisateur pendant 10 à 15 secondes.

• Problème résolu 104776 : Pour un client configurant une interface VMware SD-WAN Edge pour PPPoE, lorsque les paramètres d'overlay WAN de cette interface incluent le paramètre 802.1P, le dispositif Edge inclut les bits PRI 802.1P sur le trafic sortant.

  Le dispositif Edge n'inclut pas l'option configurable pour netifd afin de définir les « mappages de priorité de sortie » (EGRESS priority mappings) pour les interfaces PPPoE. Par conséquent, le dispositif Edge ne marque pas ces paquets avec le PRI.

• Problème résolu 104786 : Pour une entreprise cliente déployée à l'aide d'une topologie d'interconnexion du Hub ou du cluster, le rééquilibrage automatique des tunnels entre deux clusters interconnectés ne fonctionne pas.

  Le rééquilibrage des clusters interconnectés ne se produit pas lors d'un score de cluster croissant ou d'un bagotement BGP, ce qui devrait avoir lieu, et cela peut entraîner des problèmes de trafic en raison du déséquilibre de l'utilisation du tunnel.

• Problème résolu 105034 : L'interrogation SNMP pour le CPU et la mémoire du dispositif VMware SD-WAN Edge obtient toujours un zéro comme valeur de réponse.

  L'interrogation SNMP pour le CPU et la mémoire dans le cadre des statistiques de santé du dispositif Edge obtient toujours une valeur de réponse zéro. En tant que résolution, l'utilisation du CPU est désormais renommée charge de CPU moyenne et l'utilisation de la mémoire est également renseignée comme réponse.

• Problème résolu 106160 : Lorsque vous disposez d'un serveur DNS configuré par un dispositif Edge et d'une passerelle next-hop définie pour une interface Edge pour laquelle les clients interrogent le serveur DNS, aucune réponse n'est renvoyée.

  Le paquet de demande DNS est reçu par le serveur DNS Edge comme prévu. Toutefois, le paquet de réponse effectue une recherche de table de routage basée sur un suivi de connexion iptables, trouve l'adresse IP de la passerelle next-hop et résout l'adresse MAC. Il en résulte que le paquet de réponse DNS utilise l'adresse MAC de la passerelle, pas celle de l'expéditeur.

• Problème résolu 106992 : Pour une entreprise cliente déployée à l'aide d'une topologie d'interconnexion du Hub ou du cluster, le client peut observer que les clusters du Hub ne peuvent pas former d'overlays entre eux.

  Les membres des clusters du Hub sur lesquels l'interconnexion est activée peuvent ne pas être en mesure d'établir des overlays, en raison d'un mappage de clusters du Hub périmé. La seule façon de corriger ce problème consiste à désactiver, puis à réactiver l'interconnexion sur les clusters du Hub.

• Problème résolu 107550 : Pour les entreprises clientes sur lesquelles des destinations non-SD-WAN via des passerelles sont déployées, un utilisateur peut observer un abandon des paquets chiffrés IPsec dans le chemin.

  L'implémentation actuelle utilise une valeur de durée de vie (TTL) d'en-tête IP interne, ce qui ne correspond pas aux exigences de RFC. Par conséquent, la valeur TTL doit être construite et, si l'expéditeur des paquets utilise une valeur TTL faible, il est possible que ce paquet n'atteigne pas sa destination.

• Problème résolu 108111 : Lorsqu'un utilisateur opérateur ou partenaire tente de déboguer une passerelle VMware SD-WAN Gateway à l'aide de la commande debug.py --bgp_agg_dump, la commande ne dispose pas d'une chaîne d'aide appropriée.

  La chaîne d'aide explique les arguments utilisés (par exemple : [[v4 | v6 | all] ...]]) et, à cause de ce problème, la chaîne est manquante pour la commande debug.

• Problème résolu 109830 : Les combinaisons de certains clients et serveurs VPN PPTP (Point-to-Point Tunneling Protocol) peuvent ne pas être en mesure de rétablir immédiatement une connexion après son interruption lors de l'utilisation de la NAT 1:1 lorsque le serveur PPTP se trouve derrière le dispositif Edge et que le client se trouve sur Internet ou le cloud.

  Ce problème a été confirmé avec le client Windows Server 2016 et Windows 10, mais peut également se produire avec d'autres versions. Ce problème est dû à l'utilisation par le serveur du même call-id PPTP pour la nouvelle connexion alors que le client utilise un nouveau call-id. Lorsque le call-id du serveur est réutilisé pour la nouvelle connexion, le pare-feu ne l'identifie pas comme une nouvelle connexion.

  Sans correctif pour ce problème, un utilisateur peut vider la connexion PPTP périmée de la table NAT pour restaurer la connectivité.

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

  Dans des conditions de CPU élevées, plusieurs pannes de service déclenchées par un moniteur mutex peuvent se produire en raison d'un thread de priorité inférieure qui acquiert le verrou de débogage. La résolution de ce problème est une amélioration du plan de données qui rend le thread à la fois sans verrou et sans attente.

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

  Le problème provient de la gestion de la mémoire tampon réseau (SKB). Dans certains cas, la vérification d'allocation SKB est manquante, ce qui peut déclencher l'échec du service Edge.

• Problème résolu 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é.

• Problème résolu 114529 : Pour les modèles de dispositifs Edge LTE (510-LTE, 610-LTE), lorsqu'un utilisateur ne définit pas les configurations CELL dans Orchestrator, même après l'activation de CELL1/CELL2 et qu'aucun opérateur par défaut ni aucune configuration n'est sélectionnée, le dispositif Edge génère une erreur de configuration.

  Si un utilisateur active une interface CELL1/CELL2 Edge LTE à partir de la page Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) > Interface et ne sélectionne aucun opérateur/réseau dans la liste, ce champ indique que le dispositif Edge est vide et, lorsqu'il est lu, le dispositif Edge génère une erreur indiquant qu'il ne provient pas de l'un des SPN disponibles. Cette erreur est visible dans la section Evénements (Events) sur Orchestrator.

• Problème résolu 114659 : La commande de débogage tcpdump.sh ne fonctionne pas pour une passerelle VMware SD-WAN Gateway.

  Le processus de sécurité AppArmor de la passerelle bloque l'accès aux terminaux /dev/pts/*. Cela entraîne l'arrêt du processus vctcpdump et tcpdump.sh ne capture aucune information sur stdout.

  Sur une passerelle sans correctif pour ce problème, la solution consiste à exécuter la commande tcpdump.sh-w pour enregistrer la sortie dans un fichier, car cela fonctionne encore.

• Problème résolu 114854 : Pour un utilisateur dépannant un modèle de VMware SD-WAN Edge 610 avec DPDK activé, l'exécution d'une capture de paquets à partir d'Orchestrator ou à l'aide de tcpdump.sh ou de vctcpdump indique que la balise VLAN est manquante pour le trafic de retour.

  L'absence de balises VLAN sur le trafic de retour affecte la capacité d'un utilisateur à résoudre correctement un problème réseau avec n'importe quelle version d'un dispositif Edge 610.

• Problème résolu 114938 : lorsqu'un utilisateur examine Surveiller (Monitor) > Dispositifs Edge (Edges) > Destinations pour une entreprise cliente, il peut observer un nom de domaine incorrect pour une destination.

  Ces noms d'hôte non valides peuvent remplir entièrement le cache DNS du dispositif Edge et entraîner des événements Cache DNS maximal atteint (Max DNS reached), après quoi il est impossible d'ajouter les noms d'hôte valides. Ce problème est dû au fait que le moteur d'inspection approfondie des paquets (DPI, Deep Packet Inspection) du dispositif Edge ajoute des noms d'hôte non valides (comme adresse IP ou adresse IP:Port) dans le cache DNS du dispositif Edge.

  

• Problème résolu 114988 : Le message ICMPv6 « Paquet trop volumineux » (Packet Too Big) n'est pas reçu d'une passerelle VMware SD-WAN Gateway ou via celle-ci.

  Le chemin d'accès aux données de la passerelle consomme tous les messages ICMPv6 « Paquet trop volumineux » (Packet Too Big) localement. Le correctif garantit que la passerelle envoie la destination appropriée.

• Problème résolu 115148 : lorsqu'un client déploie un service de sécurité cloud avec des tunnels redondants (c'est-à-dire, actifs et passifs) et que le contrôle de santé L7 est activé, si le tunnel CSS principal devient inactif, puis redevient actif, le tunnel CSS passif peut rester actif.

  Si le tunnel passif est actif lorsque le contrôle de santé L7 est activé, puis que cette fonctionnalité est désactivée avant que le tunnel CSS principal ne redevienne actif, le tunnel passif peut rester actif indéfiniment. La cause du problème est que, même si le contrôle de santé L7 est désactivé, la passerelle vérifie l'état de L7 pour le tunnel principal et son état est lu comme étant Inactif (Down). Par conséquent, la passerelle conclut que le tunnel principal est inactif et maintient le tunnel passif actif.

  Sur un dispositif Edge sans correctif pour ce problème, si un utilisateur effectue l'opération Actions > Redémarrage du service Edge (Edge Service Restart), le problème sera résolu pour cet emplacement.

• Problème résolu 115225 : Lorsqu'un dispositif VMware SD-WAN Edge rencontre un grand nombre de bagotements de tunnel, cela peut entraîner une augmentation de l'utilisation de la mémoire en raison d'une fuite de mémoire.

  Lors de l'analyse des journaux, l'utilisateur observe une augmentation dans l'objet de mémoire vc_edge_route dans lequel il existe de nombreux bagotements de tunnel en raison de fuites de mémoire liées à la route du dispositif Edge.

• Problème résolu 115262 : Lorsqu'une entreprise cliente utilise BGP pour le routage, les BGP Neighbors avec une adresse IP secondaire peuvent ne pas s'activer sur un dispositif VMware SD-WAN Edge.

  Lorsqu'un utilisateur configure d'abord le BGP Neighbor, puis configure l'adresse IP secondaire correspondante sur une interface VLAN, la session BGP ne s'active pas, car l'interface BGP n'est pas mise à jour avec la suppression/l'ajout de l'adresse IP secondaire sur une interface VLAN.

• Problème résolu 115604 : un dispositif VMware SD-WAN Edge ou une passerelle peut subir une panne du service de plan de données et générer un vidage de mémoire avec une assertion dans la journalisation.

  Lorsqu'un dispositif Edge ou une passerelle traite un paquet endommagé, le logiciel peut rencontrer une assertion dans laquelle la longueur réelle du paquet utilisateur est supérieure à la mémoire tampon de paquets interne. La passerelle est supposée abandonner ce type de paquet et empêcher son envoi au dispositif Edge, mais au lieu de cela, elle le traite, ce qui entraîne l'échec et le redémarrage du service.

• Problème résolu 115869 : Les tunnels sont rétablis vers une passerelle VMware SD-WAN Gateway au milieu de son processus de mise à niveau.

  Dans un environnement à l'échelle dans lequel 1 000 tunnels et peers se connectent à une passerelle, lorsqu'une passerelle est mise à niveau, le trafic bascule vers la passerelle secondaire par conception pour garantir une courte interruption de service et reprendre le flux du trafic rapidement. Lorsque le script de mise à niveau est en cours d'exécution sur la passerelle (pour une mise à niveau de la version 4.5.1, 5.0.1 ou 5.1.0 vers la version 5.2.0), au milieu de l'exécution du script de mise à niveau, les tunnels commencent à se réactiver sur la passerelle et le trafic bascule de nouveau de la passerelle secondaire vers celle-ci. Ensuite, lorsque le script se termine, la passerelle nécessite un redémarrage et, une fois de plus, le trafic est commuté vers une passerelle secondaire. Cela peut entraîner des interruptions majeures du trafic client pour le trafic de type chemins multiples utilisant la passerelle.

  Sur une passerelle sans correctif pour ce problème, la solution consiste à déplacer vc_proc_mon restart du script de post-installation à après la fin de la mise à niveau.

• Problème résolu 115904 : Lorsqu'un utilisateur déclenche un bundle de diagnostics pour un dispositif VMware SD-WAN Edge à l'aide de VMware SASE Orchestrator, 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 pour reprendre.

  Un utilisateur peut générer un bundle de diagnostics du dispositif Edge sur la page SD-WAN > Diagnostics > Bundle de diagnostics (Diagnostics Bundle). Lorsque cette action est effectuée, une condition de concurrence entre dns_name_cache (ajout et/ou suppression) et le cache de noms DNS peut se produire. Le service Edge tente alors d'accéder à un élément en cours d'utilisation ou supprimé, ce qui déclenche une panne de service avec une raison SIGSEGV ou SIGBUS.

• Problème résolu 116049 : L'état du VPN d'un lien WAN configuré en tant que sauvegarde peut passer à l'état INACTIF (DEAD) au lieu de l'état EN VEILLE (STANDBY) attendu.

  L'incidence sur le client est réduite, car la fonctionnalité de lien WAN de sauvegarde (lien devenant ACTIF (ACTIVE) lorsque d'autres chemins deviennent inactifs) n'est pas affectée. Toutefois, l'état de l'interface utilisateur affiché du lien WAN comme INACTIF (DEAD) peut entraîner une confusion pour le client. Si le lien WAN de sauvegarde est en fait inactif, le client ne peut pas déterminer via la page Dispositif Edge (Edge) > Surveiller (Monitor) lorsque ce problème se produit.

  Ce problème peut se produire lorsque l'entreprise est connectée à une passerelle partenaire et que l'adresse IP de transfert BGP configurée n'est pas une adresse IP d'une interface Edge dans ce segment. Dans ce scénario, les messages de vérification du lien de sauvegarde du dispositif Edge peuvent être abandonnés. Par conséquent, les liens WAN configurés en tant que sauvegardes pour les dispositifs Edge peuvent être marqués comme INACTIF (DEAD) au lieu d'EN VEILLE (STANDBY), même si le lien est actif.

• Problème résolu 116059 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité dans lequel des VNF sont utilisées, la connectivité à une VNF du dispositif Edge en veille échoue à partir du gestionnaire de VNF présent sur le VLAN de gestion de la VNF.

  Lorsqu'un gestionnaire de VNF est déployé sur le VLAN de gestion de la VNF, une entrée d'adresse MAC incorrecte peut être apprise sur la base de données de transfert (FDB, Forwarding Database) du pont de gestion VNF en veille et cette entrée persiste même après que les ports de pont en veille sont définis sur un état désactivé. Par conséquent, la connectivité VNF du dispositif Edge en veille échoue à partir du gestionnaire de VNF.

• Problème résolu 116199 : Pour une entreprise cliente dans laquelle l'interconnexion du Hub et du cluster est configurée, lorsque le tunnel entre un dispositif Spoke Edge et un Hub ou un cluster devient inactif, les routes peuvent ne pas être révoquées des dispositifs Spoke Edge distants.

  Ce problème peut avoir une incidence sur le trafic client utilisant ces routes obsolètes et ne peut être résolu qu'en relançant temporairement les routes.

• Problème résolu 116257 : Pour un dispositif VMware SD-WAN Edge connecté via une passerelle partenaire dans laquelle un transfert NAT est configuré pour un serveur distant, le trafic de retour vers le dispositif Edge peut être abandonné à partir de ce serveur.

  Si le trafic n'est initialement pas chiffré du dispositif Edge vers le serveur distant, puis mis à jour avec un indicateur de chiffrement, une fois la route mise à jour, le trafic inverse est abandonné sur le dispositif Edge en raison d'un échec de recherche de route.

  Le problème peut être résolu temporairement en vidant les flux sur le dispositif Edge concerné.

• Problème résolu 116368 : Les journaux de routage sur une passerelle VMware SD-WAN Gateway peuvent atteindre la capacité maximale et ne pas accumuler d'entrées supplémentaires.

  Ce problème est dû au fait que le logiciel de routage de la passerelle ne dispose pas de la configuration de rotation des journaux, dont l'objectif est d'effectuer la rotation des journaux de routage avant d'atteindre la capacité afin que de nouvelles entrées de journal puissent être ajoutées. Sans cette configuration, la rotation des journaux de routage n'est pas effectuée et les opérateurs et les partenaires peuvent manquer des entrées de journaux critiques pour une passerelle.

• Problème résolu 116428 : Sur un déploiement client dans lequel plusieurs segments sont configurés et chaque segment non global dispose d'un nom personnalisé, lors de l'exécution de Diagnostics à distance (Remote Diagnostics) > Test ping (Ping Test), le menu déroulant permettant de choisir une interface n'affiche pas le nom personnalisé de chaque segment.

  Au lieu du nom personnalisé pour chaque segment non global, l'utilisateur voit un nom générique avec un nombre : Segment 1, Segment 2, etc. Cela est dû au codage en dur du nom de segment que le dispositif Edge effectue pour chaque segment non global.

  

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

  Le dispositif Edge peut rencontrer ce problème en raison d'une condition de concurrence lors du démarrage du dispositif Edge, ce qui entraîne l'échec du service Edge en raison de données non initialisées.

• Problème résolu 116894 : La règle NAT 1:1 ne fonctionne pas correctement lorsque l'adresse IP externe et l'adresse IP source se trouvent dans le même sous-réseau.

  Avec la configuration NAT 1:1, le dispositif Edge modifie le port source lors de la traduction NAT, ce qui entraîne l'abandon du trafic entrant qui correspond à cette règle.

• Problème résolu 116916 : Les chemins du dispositif Edge vers les dispositifs Edge et les passerelles peer peuvent s'arrêter après l'ajout ou la suppression d'une route par défaut du noyau IPv6 vers n'importe quelle destination via une interface Edge utilisée par le processus de gestion du dispositif Edge.

  Les chemins du dispositif Edge peuvent devenir inactifs lors de l'ajout ou de la suppression d'une route par défaut du noyau IPv6 impliquant n'importe quelle interface utilisée par le processus de gestion du dispositif Edge pour former des chemins avec d'autres nœuds (c'est-à-dire, dispositifs Edge ou passerelles).

  Si ce problème se produit sans correctif, vous devez supprimer la route IPv6 et redémarrer le service.

• Problème résolu 116925 : Le trafic FTP peut être classé de manière incorrecte comme TCP générique par le moteur d'inspection approfondie des paquets (DPI, Deep Packet Inspection) du dispositif VMware SD-WAN Edge.

  Lorsque cela se produit, cela a une incidence importante pour un client qui utilise une business policy ou une règle de pare-feu destinée à faire correspondre le trafic FTP, car la règle ne fonctionne pas.

  Le trafic de données FTP est classé comme APP_TCP au lieu de APP_FTP_DATA. Cela est dû à la suppression des flux de contrôle FTP du contexte du moteur DPI une fois la classification terminée. Toutefois, pour que le trafic de données FTP soit correctement classé, le flux doit persister dans le moteur DPI.

• Problème résolu 117037 : pour un client utilisant une topologie Hub/Spoke dans laquelle plusieurs liens WAN sont utilisés pour envoyer et recevoir du 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.

  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 résolu 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.

  videz les flux pour créer des flux ICMP et corriger temporairement le problème.

• Problème résolu 117320 : Pour un client sur lequel le pare-feu avec état et Syslog sont activés, les messages Syslog pour le trafic qui correspond à une règle NAT côté LAN n'incluent pas l'adresse IP source.

  Un message Syslog complet pour un trafic doit inclure l'adresse IP source, en particulier pour le trafic avec NAT.

• Problème résolu 117831 : Les règles de pare-feu par défaut de VMware SD-WAN Gateway empêchent l'agent Linux Azure de communiquer avec l'infrastructure Azure après le démarrage du service SD-WAN.

  Cela n'affecte pas la fonctionnalité SD-WAN, mais certaines mesures peuvent être manquantes dans le portail Azure pour la machine virtuelle de la passerelle.

  L'agent Azure Linux requiert une communication sortante sur les ports 80/TCP et 32526/TCP avec WireServer (168.63.129.16). Après le démarrage du service de passerelle, le port 32526 est bloqué.

• Problème résolu 117838 : 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.

  Ce problème peut se produire lorsque le dispositif Edge reçoit un paquet ike avec une version non correspondante par rapport à ike_ds. L'incident se produit lorsque le service Edge traite des paquets de version non correspondante et place un verrou mutex afin de modifier une valeur de cookie dans ike_ds. Toutefois, si une non-correspondance de version survient, le dispositif Edge déclenche une suppression d'association de sécurité (SA, Security Association) qui tente à nouveau de placer un verrou mutex sur le même ike_ds. Il en résulte un blocage du dispositif Edge, une panne de service, puis un redémarrage.

• Problème résolu 117943 : sur un dispositif VMware SD-WAN Edge avec capacité Wi-Fi, la sélection automatique des canaux pour certains pays peut forcer le dispositif Edge à choisir les canaux, ce qui entraîne des performances Wi-Fi médiocres ou même l'échec complet de l'activation du Wi-Fi.

  Dans certains pays comme la Grande-Bretagne, le Wi-Fi prend beaucoup de temps à apparaître lorsqu'il est configuré pour la bande 5 GHz (ou peut même ne pas s'afficher). La sélection automatique des canaux pour la bande 5 GHz peut finir par sélectionner des canaux inappropriés dans certains pays : soit des canaux à très faible puissance, soit des canaux qui nécessitent une détection radar (ce qui peut retarder ou faire échouer le démarrage).

  Sur un dispositif Edge sans correctif pour ce problème, lors de la sélection de la bande 5 GHz dans un pays européen, configurez explicitement le canal radio sur 36, 40, 44 ou 48 (au lieu de le laisser sur « auto »).

• Problème résolu 118097 : Un utilisateur opérateur ou partenaire lors du débogage d'une passerelle VMware SD-WAN Gateway peut constater que la commande debug.py --path ne renvoie aucun résultat.

  Ce problème est dû à une clé non gérée lorsqu'un tunnel temporaire est présent, ce qui interrompt la commande debug.py --path pendant que la passerelle traite les chemins temporaires.

• Problème résolu 118348 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité améliorée, si un utilisateur active DHCP sur une sous-interface d'un dispositif VMware SD-WAN Edge, le dispositif Edge HA peut rencontrer un échec du service de plan de données, générer un vidage de mémoire et redémarrer pour reprendre.

  Si cela se produit sur le dispositif Edge actif, cela déclenche un basculement HA et le dispositif en veille est promu. Si cela se produit sur le dispositif en veille, aucun basculement n'a lieu, mais le trafic utilisant le ou les liens WAN du dispositif Edge en veille sera brièvement interrompu.

• Problème résolu 118436 : Le trafic DNS vers un serveur DNS d'underlay peut ne pas fonctionner.

  Ce problème peut se produire lorsqu'une interface routée d'un dispositif VMware SD-WAN Edge est configurée sans adresse IPv6 de la passerelle et de DHCPv6 avec interface en tant qu'adresse IP de serveur DNS, mais sans route par défaut IPv6 sur une passerelle partenaire. Dans cette configuration, la réponse DNS de l'underlay est abandonnée par le dispositif Edge.

• Problème résolu 118591 : Pour un site d'entreprise client utilisant une topologie à haute disponibilité améliorée, le dispositif Edge HA en veille peut rencontrer de fréquents bagotements d'interface.

  Dans un déploiement à HA améliorée, lorsqu'un nombre élevé de flux est envoyé ou qu'un nombre élevé de routes est installé, l'état de l'interface du dispositif Edge en veille peut passer d'ACTIF (UP) à INACTIF (DOWN), puis de nouveau à ACTIF (UP).

• Problème résolu 119010 : Sur les modèles 520 et 540 de VMware SD-WAN Edge, le dispositif Edge peut ne pas transférer le trafic d'un VLAN situé sur les ports LAN 1 à 4 vers un VLAN situé sur les ports LAN 5 à 8, et inversement.

  Les modèles de dispositifs Edge 520 et 540 disposent de deux cartes réseau LAN, chacune avec une banque de quatre ports pour un total de 8 ports LAN. Lorsqu'un LAN est configuré pour un port LAN sur la première banque de ports et un VLAN différent est configuré pour un port LAN sur la deuxième banque de ports, le dispositif Edge ne gère pas correctement ce trafic et il est abandonné.

• Problème résolu 119033 : Lors d'un démarrage, la passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données et devoir redémarrer pour récupérer.

  Les détails des allocations de ports NAT sont stockés dans un segment de mémoire partagée en dehors du processus du service de passerelle (géré par le processus NAD) par conception. Cela permet de s'assurer que le service de passerelle peut rapidement réinitialiser sa table NAT lors du redémarrage du processus. Toutefois, il est possible que cet état persistant soit endommagé, ce qui entraîne l'échec du service de passerelle immédiatement après le redémarrage.

  Sur une passerelle sans correctif pour ce problème, le vidage de la table NAT ou le redémarrage du système d'exploitation peut l'empêcher de se produire.

• Problème résolu 119466 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité, le trafic correspondant à la règle NAT Plusieurs:1 peut échouer après un basculement HA.

  Lorsque ce problème se produit, les entrées NAT côté LAN ne sont pas synchronisées avec le dispositif Edge en veille. Étant donné que la règle NAT Plusieurs:1 implique également la traduction d'adresses de port (PAT, Port Address Translation), les entrées NAT côté LAN ne peuvent pas être créées en fonction de la configuration et doivent être synchronisées pour éviter une interruption du trafic lors d'un basculement HA.

• Problème résolu 119544 : Lorsque l'option Réponse ECHO ICMP (ICMP Echo Response) est désactivée sur une interface Loopback d'un dispositif VMware SD-WAN Edge, le contrôle de santé L7 échoue et le dispositif Edge lance la désactivation du tunnel CSS sur lequel le contrôle de santé L7 est configuré.

  En outre, lorsque le trafic de gestion passe directement, la communication entre le dispositif Edge et Orchestrator est également perdue.

  Lorsque le dispositif Edge tente d'envoyer une demande de contrôle de santé L7 (paquet HTTP SYN), celle-ci atteint l'interface Loopback, mais comme l'option Réponse ECHO ICMP (ICMP Echo Response) est désactivée, les paquets HTTP sont abandonnés. Lorsque le contrôle de santé L7 n'obtient aucun ACK pour le paquet SYN qu'il a envoyé, il échoue et entraîne une désactivation du tunnel CSS.

  De même, lorsque le dispositif Edge tente d'envoyer des paquets HTTPS à Orchestrator, il atteint l'interface Loopback, mais comme l'option Réponse ECHO ICMP (ICMP Echo Response) est désactivée, les paquets HTTPS ACK sont abandonnés.

• Problème résolu 119811 : Un client peut observer dans sa liste Événements (Events) plusieurs événements Edge MGD_WEBSOCKET_INIT et MGD_WEBSOCKET_CLOSE par jour.

  Plusieurs événements MGD_WEBSOCKET_INIT et MGD_WEBSOCKET_CLOSE peuvent être affichés dans la liste Événements (Events) d'Orchestrator sans aucune action du client.

  Ces messages d'événement sont trompeurs et peuvent être ignorés en toute sécurité, car leur niveau de gravité est « Infos » (Info).

• Problème résolu 120940 : S'il existe plusieurs routes pour le même préfixe dans BGP à partir de différents Neighbors dans le même VRF interne (comme un VRF créé pour des destinations non-SD-WAN via des sessions BGP de passerelle), la même adresse IP de Neighbor est mise à jour pour toutes les routes.

  Ce problème peut être observé sur SD-WAN Gateway à l'aide des commandes debug.py --routes et debug.py --bgp_view outputs. Il est dû au processus de routage d'une passerelle qui ne met pas correctement à jour l'adresse IP du Neighbor (source).

• Problème résolu 121024 : Le trafic du service d'accès à distance (RAS, Remote Access Service) échoue lorsqu'un trafic Internet correspondant à une business policy est configuré sur un dispositif VMware SD-WAN Edge.

  Lorsqu'un trafic Internet correspondant à une business policy est configuré sur un dispositif Edge et que l'action consiste à diriger ce trafic directement, pour tout trafic du service d'accès à distance qui atteint ce dispositif Edge, le trafic de retour correspond à la business policy et il est abandonné sur le dispositif Edge.

  La seule solution consiste à configurer une business policy plus spécifique correspondant à des sous-réseaux RAS et à définir l'action pour un envoi sur des chemins multiples (via la passerelle).

• Problème résolu 121338 : Pour un site sur lequel un lien WAN est configuré pour être en veille à chaud, le dispositif VMware SD-WAN Edge inclut ce lien dans la bande passante disponible.

  Un lien WAN en veille à chaud est inactif de par sa conception et ne doit pas être inclus dans la bande passante disponible d'un dispositif Edge. Étant donné que la veille à chaud est incluse, le dispositif Edge effectue des calculs inexacts pour la bande passante totale disponible et peut entraîner une perte de paquets.

• Problème résolu 121513 : Pour une entreprise cliente utilisant une passerelle partenaire sur laquelle l'option « Routes BGP sécurisées » (Secure BGP Routes) est activée, les utilisateurs clients peuvent observer des problèmes de qualité du trafic.

  Le trafic peut être abandonné sur les dispositifs Edge lorsqu'il est initié avec une adresse IP de peer BGP en tant que source derrière une passerelle partenaire et que des Routes BGP sécurisées (Secure BGP Routes) sont configurées. Cela est dû au fait que lorsque le trafic est initié à partir d'un point de terminaison BGP en tant que source, il crée un flux non sécurisé dans la passerelle, car la route source sera de type BGP-Peer, pour lequel la gestion des paramètres sécurisés n'est pas effectuée. Toutefois, si la recherche de route source sur les dispositifs Edge renvoie une route sécurisée, le paramètre sécurisé du trafic entrant et de la recherche de routes ne correspond pas. Cela entraîne l'échec de la recherche de route source sur les dispositifs Edge.

• Problème résolu 121606 : Les clients connectés à une passerelle partenaire peuvent observer que les tunnels VPN IPsec sont inactifs sur la passerelle partenaire.

  Le processus IPsec des passerelles prend en charge un maximum de 64 adresses IP sur une interface. Pour ce problème sur une passerelle partenaire, les adresses IP de transfert sont ajoutées sans condition à l'interface de processus IPsec de la passerelle. 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.

  Lorsque ce problème se produit sur une passerelle sans correctif pour celui-ci, il n'existe aucune solution réelle en supposant que toutes les adresses IP de transfert de la passerelle partenaire sont configurées comme prévu. Dans le cas contraire, la suppression des adresses IP de transfert de la passerelle partenaire inutiles peut permettre de réduire le nombre d'adresses IP sur le processus IPsec de la passerelle à moins de 64. Un redémarrage du service de passerelle sera nécessaire après la modification de la configuration.

  Outre cette solution, une solution plus réaliste consiste à déplacer un nombre de tunnels IPsec vers une deuxième passerelle partenaire suffisante pour réduire le nombre total de transferts à moins de 64 sur la passerelle partenaire affectée.

• Problème résolu 121815 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité et qui utilise des VNF, lorsqu'un dispositif Edge en veille dispose d'une interface LAN active et d'une VNF inactive, et que le dispositif Edge actif dispose d'une interface LAN inactive et d'une VNF active, il n'y a pas de basculement HA, car même le dispositif Edge en veille dispose d'un port LAN actif.

  Ce problème provient du dispositif Edge incluant l'état de VNF dans le cadre du nombre de LAN dans le signal de pulsation HA. Une VNF active est comptabilisée comme un LAN supplémentaire et entraîne les symptômes répertoriés.

  Ce problème est résolu en découplant tous les états de VNF du nombre de LAN afin que les décisions de basculement HA puissent être prises correctement. Avec cette modification, le dispositif Edge accorde une priorité plus élevée à une VNF lorsqu'il dispose d'une connectivité WAN et LAN de base active. En d'autres termes, si le dispositif Edge actif dispose d'une VNF inactive et que le dispositif Edge en veille dispose d'une VNF active, le dispositif Edge en veille est promu comme Actif s'il dispose d'au moins 1 WAN et 1 LAN, et ce, quel que soit le nombre de LAN/WAN sur le dispositif Edge actif.

• Problème résolu 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.

  Pour un dispositif Edge sans correctif pour ce problème, un client peut modifier la Source d'un VLAN Edge sur « Indifférent » (Any).

• Problème résolu 122029 : Un service de sécurité cloud (généralement, Zscaler) déployé avec l'automatisation GRE sur lequel le dispositif VMware SD-WAN Edge utilise une version 5.2.x ne fonctionne pas.

  Ce problème est dû au fait que l'adresse IP locale et les adresses IP publiques ne sont pas envoyées. Ces informations sont requises pour qu'Orchestrator envoie un état de configuration du tunnel au dispositif Edge. Le tunnel doit être dans un état d'attente pour qu'Orchestrator envoie la configuration GRE automatisée.

  Ce problème est limité aux dispositifs Edge 5.2.x et un utilisateur peut le contourner uniquement en rétrogradant le dispositif Edge vers une version 5.1.x ou une version antérieure, en activant le tunnel, puis en procédant à la mise à niveau vers la version 5.2 ou une version ultérieure.

• Problème résolu 122528 : pour une entreprise cliente qui utilise des routes statiques WAN avec des sondes ICMP configurées, ces sondes peuvent cesser de fonctionner sur plusieurs dispositifs VMware SD-WAN Edge à la fois, entraînant l'abandon de tout le trafic utilisant ces routes.

  Chaque dispositif Edge dispose d'un compteur de séquences de sondes ICMP avec un nombre maximal d'itérations égal à 65 535. Lorsque ce compteur bascule après 65 535 itérations, les sondes échouent.

  Sur un dispositif Edge sans correctif pour ce problème, la solution consiste à supprimer la sonde ICMP, à redémarrer le service Edge, puis à restaurer la sonde.

• Problème résolu 123144 : Lorsque la page de l'interface utilisateur d'Orchestrator Surveiller (Monitor) > Dispositifs Edge (Edge) > Destinations est affichée, elle indique des noms de domaine de destination non valides.

  Le dispositif Edge envoie des noms de destination non valides, tels que IP:port, qui s'affichent dans l'interface utilisateur d'Orchestrator en raison d'un échec de validation dans les noms d'hôte DNS.

• Problème résolu 123237 : Pour un dispositif VMware SD-WAN Edge exécutant la version 5.2.x et sur lequel les interfaces sont configurées avec IPv6 uniquement, la page Diagnostics > Diagnostics à distance (Remote Diagnostics) ne se charge pas.

  Lorsque les interfaces Edge IPv6 uniquement sont configurées avec des paramètres IPv4 désactivés, une exception est générée dans un script de clé, ce qui empêche le chargement de la page Diagnostics > Diagnostics à distance (Remote Diagnostics).

  La solution consiste à activer les paramètres IPv4 avec une configuration factice.

• Problème résolu 123956 : Un utilisateur ne peut pas accéder à l'interface utilisateur locale sur un dispositif VMware SD-WAN Edge à l'aide d'une version 5.2.x.

  La page du navigateur ne se charge pas et renvoie une erreur 404. Ce problème est dû à des exceptions générées dans les scripts de diagnostics à distance et d'interface utilisateur locale.

• Problème résolu 124106 : Lorsqu'une NAT côté LAN est configurée pour des traductions Plusieurs:1 dans lesquelles la traduction d'adresses de port (PAT, Port Address Translations) est utilisée, le trafic initié en sens contraire autorise un accès inattendu à des adresses fixes basées sur le masque externe et l'adresse IP d'origine.

  Les règles NAT côté LAN permettent d'initier les connexions dans les deux sens pour les règles Plusieurs:1 sans empêcher clairement le trafic dans le sens 1:plusieurs. Les traductions 1:plusieurs seront désormais bloquées et les utilisateurs doivent créer des règles NAT 1:1 explicites pour activer le trafic.

  Ce problème est entièrement traité dans Remarques importantes : Modification du comportement de la NAT côté LAN.

• Problème résolu 124162 : Lorsqu'un utilisateur effectue une capture de paquets sur une interface VMware SD-WAN Edge, un paquet semble endommagé.

  Il n'y a pas de corruption réelle du paquet qui apparaît uniquement endommagé dans le fichier PCAP. Ce problème est dû à un défaut dans la manière dont le dispositif Edge écrit les paquets dans l'interface de capture de paquets. Les paquets balisés par VLAN peuvent être écrits de manière incorrecte et et s'afficher sous forme de paquet corrompu (valeur ether-type non valide) dans le fichier PCAP.

• Problème résolu 124263 : Un client peut observer une utilisation élevée du CPU sur un dispositif VMware SD-WAN Edge lors du traitement des paquets d'encapsulation de détection des Neighbors (ND, Neighbor Discovery) IPv6 et L2.

  Le dépannage du dispositif Edge pointe vers api - vc_ip6_host_addr_to_network_addr qui consomme une quantité élevée de CPU.

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

  Lorsqu'une business policy est configurée avec un backhaul Internet et qu'un paquet de 3 000 octets ou plus est envoyé du côté LAN, le processus Edge attend des paquets de grande taille, ce qui déclenche une panne de service.

• Problème résolu 125035 : Lorsqu'un client déploie une VNF Fortinet 6.4.x, l'adresse IP de gestion du dispositif Edge n'est pas accessible.

  Fortinet a apporté des modifications à la version 6.4.x, qui empêchent l'utilisation simultanée de FortiLink et du mode transparent. SD-WAN n'utilise pas FortiLink et, par conséquent, la résolution de ce problème consiste à désactiver FortiLink avant de définir le mode transparent lors du déploiement de la VNF.

• Problème résolu 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.

• Problème résolu 125487 : Le flux de trafic entre deux dispositifs Edge peut être interrompu par un problème de résolution ARP.

  Lorsque ce problème se produit, le dispositif Edge transfère la demande ARP à l'adresse IP du next-hop à l'aide de l'adresse IP de l'interface principale au lieu de l'adresse IP de la sous-interface. Ce problème se produit lors de la création du flux lorsqu'une route non connectée est utilisée pour atteindre la destination. Si la sous-interface du dispositif Edge est utilisée pour cette connectivité, le dispositif Edge ne remplit pas correctement l'adresse IP source pour le cas de la sous-interface.

• Problème résolu 126304 : Les règles NAT 1:1, dont la traduction source chevauche les règles NAT Plusieurs:1 ou d'autres règles NAT 1 :1, peuvent entraîner des collisions de port ou l'échec des traductions.

  Pour corriger ce comportement, lorsqu'une traduction source de règle NAT 1 :1 chevauche une autre règle, la traduction d'adresses de port (PAT, Port Address Translation) est également activée pour la règle NAT 1:1.

• Problème résolu 126458 : Pour un site client déployé avec une topologie haute disponibilité dans laquelle les dispositifs Edge HA sont des modèles de dispositifs Edge 520/540, le client peut observer plusieurs basculements HA résultant d'un état Actif/Actif (Active/Active).

  La condition est déclenchée sur les dispositifs Edge 520/540 configurés avec HA lorsque le nombre de flux simultanés dépasse 300 000.

  Sur les dispositifs Edge 520/540 HA sans correctif pour ce problème, la solution consiste à augmenter le temps de basculement HA de 700 ms à 7 000 ms sur la page Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device), car cela réduit la modification d'un état Actif/Actif (Active/Active).

• Problème résolu 127127 : Un dispositif VMware SD-WAN Edge n'apprend pas les routes des dispositifs Edge du Hub lorsque les passerelles VMware SD-WAN Gateway sont mises à niveau vers la version 5.1.x ou une version ultérieure.

  Lorsque la configuration d'un dispositif Edge est site distant vers site distant via des Hubs avec uniquement le même dispositif Edge dans la liste et que la passerelle exécute la version 5.1.x et des versions ultérieures, les routes ne sont pas annoncées de la passerelle vers le dispositif Edge.

  La seule solution consiste à supprimer le dispositif Edge de la configuration site distant vers site distant via des Hubs.

• Problème résolu 127403 : Sur la page Tester et dépanner (Test & Troubleshoot) > Diagnostics à distance (Remote Diagnostics) de l'interface utilisateur d'Orchestrator, lors de l'exécution du diagnostic à distance Dépanner OSPF - Répertorier les routes redistribuées OSPF (Troubleshoot OSPF - List OSPF Redistributed Routes) ou Dépanner BGP - Répertorier les routes redistribuées BGP (TroubleshootBGP - List BGP Redistributed Routes), le test renvoie une erreur sans données.

  Après l'exécution de l'un ou l'autre des diagnostics, l'utilisateur observe une erreur : Erreur lors de la lecture des données pour le test.

• Problème résolu 128377 : Pour une entreprise cliente utilisant BGP pour le routage, le client peut observer que le trafic utilisateur est interrompu en raison d'un échec de BGP.

  Le processus BGP peut se bloquer lors du nettoyage en raison d'un accès à la mémoire non valide de self_mac_hash.

  Dans le cadre du nettoyage de bgp_master, self_mac_hash est déjà nettoyé. Cependant, lors du traitement du message après le nettoyage, BGP accède au hachage supprimé, ce qui entraîne un échec.

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

  Lorsqu'un paquet de gestion valide arrive de manière inattendue sur un tunnel IPsec de destination non-SD-WAN ou une interface GENEVE, la passerelle peut rencontrer une erreur lors du traitement de ce paquet, ce qui entraîne l'échec du processus du service de passerelle.

Problèmes d'Orchestrator résolus

• Résolu dans Orchestrator version R5401-20231115-GA.
• Résolu dans Orchestrator version R5400-20231020-GA.

Résolu dans Orchestrator version R5401-20231115-GA.

La build R5401-20231115-GA d'Orchestrator a été publiée le 15/11/2023 et constitue la 1re build cumulative d'Orchestrator pour la version 5.4.0.

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

• Problème résolu 117138 : Lorsque vous utilisez l'automatisation Zscaler pour créer un service de sécurité cloud (CSS) Zscaler, les tunnels IPsec entre le dispositif Edge et le CSS Zscaler peuvent ne pas être créés.

  Orchestrator garantit la mise en file d'attente d'une seule action par dispositif Edge. Cependant, si une action est bloquée à l'état NOTIFIÉ (NOTIFIED), toutes les actions suivantes ne sont pas exécutées et les tunnels IPsec ne sont pas créés.

  Sur un dispositif Orchestrator sans correctif pour ce problème, un utilisateur opérateur doit supprimer manuellement l'action du dispositif Edge périmée de la base de données Orchestrator.

• Problème résolu 123078 : Lorsque vous utilisez l'interface utilisateur de VMware SASE Orchestrator et que vous accédez à la page Surveiller (Monitor) > Dispositif Edge (Edge) > Présentation (Overview), les colonnes ne sont pas correctement alignées et sont difficiles à lire.

  L'interface utilisateur n'inclut aucune information pour la colonne Numéro de série du périphérique (Device Serial No), ce qui signifie qu'il y a 11 colonnes, mais seulement 10 en-têtes, ce qui entraîne un problème de lisibilité.

• Problème résolu 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.

• Problème résolu 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.

  Cela entraîne une confusion pour un utilisateur client qui configure ces paramètres sans savoir qu'il ne devrait pas le faire, car la version IPv6 d'OSPF n'est pas appliquée.

• Problème résolu 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).

  Le client utilise l'ancienne interface utilisateur pour terminer la tâche.

• Problème résolu 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 127727 : Lors de la création d'un service de sécurité cloud (CSS), un utilisateur ne peut pas configurer l'option Préférence domestique (Domestic Preference).

  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 127774 : Sous Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) > Connectivité (Connectivity) > Interfaces Loopback (Loopback Interfaces), un utilisateur tentant de configurer une interface Loopback peut ne pas réussir.

  Lorsque ce problème se produit, un utilisateur configure une interface Loopback pour un dispositif Edge et enregistre les modifications (Saves Changes). L'interface utilisateur ne génère alors pas d'erreur, mais la configuration n'est pas appliquée et ne s'affiche pas sur la page de l'interface utilisateur.

• Problème résolu 127843 : L'interface utilisateur ne s'affiche pas correctement lorsqu'elle est localisée en italien.

  Cela a une incidence sur l'utilisateur, car certains onglets de navigation se chevauchent.

• Problème résolu 128017 : Un client peut observer que lors de l'accès à la page Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device), la page ne se charge jamais.

  Lorsque ce problème se produit, les références de configuration du dispositif Edge sont supprimées par erreur de la base de données par Orchestrator. Une fois ces références supprimées, elles ne peuvent pas être restaurées.

  Sur un dispositif Orchestrator sans correctif pour ce problème, la seule solution consiste à forcer le dispositif Edge à utiliser toutes les configurations du profil associé à ce dispositif Edge. Si ce dernier dispose de nombreuses configurations personnalisées de remplacement du dispositif Edge, cela implique la création d'un profil spécial uniquement pour ce dispositif Edge.

• Problème résolu 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.

  Un utilisateur observe l'actualisation indéfinie de l'écran Mot de passe expiré (Expired Password). Pour résoudre ce problème, un opérateur ou un partenaire doit disposer du rôle approprié pour réinitialiser le mot de passe de l'utilisateur.

• Problème résolu 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 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 incluent un nombre de routes bien au-delà de la limite stricte de 256.

• Problème résolu 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 Toujours (Always) et Conditionnelle (Conditional). Aucun (None) n'est pas une option valide et ne doit pas s'afficher sur l'interface utilisateur.

• Problème résolu 128765 : Sur la page Filtres BGP (BGP Filters), le bouton Envoyer (Submit) peut rester inaccessible si l'utilisateur change de page.

  Lorsqu'un utilisateur modifie le tableau Filtres BGP (BGP Filters) et accède à une autre page avec un état non valide sur une page actuelle, les contrôles ne sont pas valides lorsqu'il revient en arrière et renseigne les informations correctes.

  Sur un dispositif Orchestrator sans correctif pour ce problème, un utilisateur doit rester sur la page du tableau dans laquelle le contrôle n'est pas valide. L'utilisateur peut également supprimer cette ligne et la rajouter.

• Problème résolu 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 129494 : Sur la page Client (Customer) > Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration) > Configuration des services (Service Configuration) > SD-WAN, l'utilisateur doit ajouter le nom de domaine lorsqu'il modifie la configuration des services.

  L'utilisateur doit le faire même si l'authentification Single Sign-On (SSO) ou l'application Edge Network Intelligence (ENI) n'est pas configurée pour le client. Un nom de domaine n'est pas obligatoire si un client n'utilise pas ENI ou SSO.

• Problème résolu n °129584 : Sur la page Configurer (Configure) > Dispositifs Edge (Edges) > Business Policy, lorsqu'un utilisateur d'Orchestrator modifie une règle de Business Policy existante, l'interface utilisateur d'Orchestrator 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 129756 : Lorsqu'un opérateur exécute le schéma de mise à jour d'un dispositif VMware SASE Orchestrator basé sur le cloud, Orchestrator peut ne pas être en mesure de se connecter à la base de données distante.

  Ce problème n'a pas d'incidence sur les dispositifs Orchestrator basés sur une VM.

• Problème résolu 129765 : Lors de la modification d'une interface routée pour un dispositif VMware SD-WAN Edge, l'interface utilisateur d'Orchestrator renseigne 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 129894 : Dans le portail de l'opérateur de l'interface utilisateur d'Orchestrator, 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.

• Problème résolu 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 dans le menu Surveiller (Monitor) > Dispositifs Edge (Edges) > Sélectionner le dispositif Edge (Select Edge) > Raccourcis (Shortcuts) > Actions à distance (Remote Actions).

  Cela empêche les utilisateurs du rôle de support d'effectuer un redémarrage du service Edge dans le menu Raccourcis (Shortcuts) de la page Surveiller (Monitor) > Dispositifs Edge (Edges).

• Problème résolu 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 de Routes locales (Local Routes) sont redéfinis en S/O (N/A) et ne peuvent pas être modifiés. Les journaux local_routes de ce dispositif Edge indiquent "reachable": "False" pour les routes locales affectées.

  Ce problème peut se produire lorsque l'adresse IP next-hop d'une route statique se trouve dans le même sous-réseau du réseau VLAN. Dans ce scénario, l'interface utilisateur d'Orchestrator supprime l'interface de la route statique, ce qui entraîne l'accessibilité de ces routes locales indiquant false.

• Problème résolu 131846 : Sur la page Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration) > Transfert aux partenaires (Partner Hand off) > Interface de transfert (Hand Off Interface) de l'interface utilisateur d'Orchestrator, l'interface utilisateur renvoie un message d'erreur lorsqu'un utilisateur clique sur le bouton Ajouter (Add) pour ajouter une route statique.

  Lorsque l'utilisateur clique sur le bouton Ajouter (Add) dans la section des routes statiques, une nouvelle ligne vide est ajoutée au tableau, mais un message d'erreur indiquant « Impossible d'enregistrer les modifications. Votre configuration comporte une ou plusieurs erreurs. » (Cannot save changes. There is one or more errors in your configuration) s'affiche. Cela est dû à une validation manquante pour la configuration des routes statiques vides dans la section Transfert aux partenaires (Partner Handoff) de l'écran Paramètres globaux (Global Settings). Ce problème affecte alors uniquement les lignes dans lesquelles aucune information n'est configurée.

  Il existe deux solutions à ce problème :

  • Remplissez tous les champs obligatoires. Ce faisant, le message d'erreur (« Impossible d'enregistrer les modifications… ») sera automatiquement résolu.

  • Supprimez de la section toutes les lignes vides récemment ajoutées. Après la suppression de ces lignes vides, le message d'erreur sera automatiquement résolu.

Résolu dans Orchestrator version R5400-20231020-GA.

La version R5400-20231020-GA d'Orchestrator a été publiée le 23/10/2023 et résout les problèmes suivants depuis Orchestrator version R5302-20231011-GA.

Note:

La version 5.4.0 contient tous les correctifs d'Orchestrator répertoriés dans les Notes de mise à jour de la version 5.2.0 jusqu'à la version 5.2.0.3 (R5203-20230809-GA) et tous les correctifs d'Orchestrator dans les Notes de mise à jour de la version 5.3.0 jusqu'à la version 5.3.0.2 (R5302-20231011-GA).

• Problème résolu 48230 : Lorsque sur la page Surveiller (Monitor) > Dispositifs Edge (Edges), la recherche de dispositifs Edge à l'aide de « Modèle » (Model) n'est pas totalement précise.

  Lorsqu'un utilisateur filtre par numéro de modèle, Orchestrator renvoie des dispositifs Edge supplémentaires.

• Problème résolu 48609 : Sur la page Surveiller (Monitor) > Routage (Routing), un utilisateur ne peut pas trier le nom de segment dans une table de routage multicast.

  Dans la version 5.4.0, l'API a été améliorée pour accepter le nom de segment en tant que paramètre de tri et permet de trier le nom du segment.

• Problème résolu 78581 : Un utilisateur peut annoncer un VLAN lorsque des routes connectées sont désactivées sur l'interface utilisateur d'Orchestrator.

  Cette action doit être rejetée par Orchestrator avec le renvoi d'une erreur. Dans la version fixe, l'interface utilisateur d'Orchestrator écoute les routes connectées et désactive l'indicateur d'annonce basé sur les routes connectées et inversement.

• Problème résolu 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.

  Sur un dispositif Orchestrator sans correctif pour ce problème, le client doit vérifier tous les paramètres du périphérique VLAN et s'assurer qu'ils sont valides, car Orchestrator ne les vérifie pas.

• Problème résolu 91869 : Lorsqu'un utilisateur opérateur accède à Gérer les partenaires (Manage Partners) et clique sur le bouton Ajouter un profil d'opérateur (Add Operator Profile), la description du profil d'opérateur est tronquée lorsqu'elle dépasse une certaine longueur de texte.

  Orchestrator ne doit pas tronquer la description du profil d'opérateur, quelle que soit la longueur du texte.

• Problème résolu 92766 : Sur la page Surveiller (Monitor) > Routage (Routing), les informations de pagination sont incorrectes.

  Si un utilisateur clique sur le bouton Suivant (Next), la page de l'interface utilisateur ne s'arrête pas même après avoir atteint la dernière page, car la logique de filtre n'est pas appliquée correctement et le numéro de page affiché n'est pas correct.

• Problème résolu 102121 : Lorsque la configuration Secure Access d'un dispositif Edge est mise à jour plusieurs fois sans aucune mise à jour de la configuration du pare-feu du dispositif Edge lors de l'utilisation de l'interface utilisateur d'Orchestrator, l'envoi aux dispositifs Edge des mises à jour de la configuration de Secure Access peut cesser.

  Ce problème se produit le plus souvent lors de tests au cours desquels l'équipe d'ingénierie force délibérément un grand nombre de mises à jour de Secure Access sans aucune mise à jour du pare-feu. Toutefois, il peut, dans de rares cas, être déclenché par un client sur le terrain.

  Si ce problème se produit sur un dispositif Orchestrator sans correctif, un utilisateur peut mettre à jour manuellement la configuration du pare-feu du dispositif Edge à partir de l'interface utilisateur une seule fois. Après la mise à jour manuelle du pare-feu, l'utilisateur peut restaurer la modification de la configuration Secure Access du dispositif Edge à partir de l'interface utilisateur et Orchestrator transfère la modification de la configuration Secure Access du dispositif Edge de l'interface utilisateur vers les dispositifs Edge.

• Problème résolu 103828 : Le filtre de recherche d'application de l'éditeur de carte d'application est peu clair.

  Cela rend la vérification ou la modification de la configuration d'une application très difficile, car une pagination manuelle est requise sur de nombreuses pages d'applications pour trouver l'application qui vous intéresse.

• Problème résolu 104395 : La section « Liens inactifs » (Links Down) de la page Surveiller (Monitor) > Réseau (Network) > Présentation (Overview) n'affiche que les 10 premiers sites comportant des liens inactifs. Lorsqu'un utilisateur clique sur le bouton « Tout afficher » (View All), l'interface utilisateur d'Orchestrator dirige l'utilisateur vers la section Dispositifs Edge (Edges) qui répertorie tous les dispositifs Edge, quel que soit l'état du lien, même si l'utilisateur souhaite uniquement voir les sites comportant des dispositifs Edge dont un ou plusieurs liens sont inactifs.

  Lorsqu'un utilisateur clique sur l'icône « Liens inactifs » (Links Down), la liste doit afficher tous les liens descendants, pas seulement 10 liens, et il n'est pas possible de filtrer les dispositifs Edge par lien ou état du dispositif Edge après avoir cliqué sur le bouton « Tout Afficher » (Show All).

• Problème résolu 108285 : Lors de la configuration d'un profil sur l'interface utilisateur d'Orchestrator, si un utilisateur modifie une interface Edge de commutée à routée, Orchestrator ajoute la nouvelle interface routée à la fin de l'interface routée au lieu de l'insérer dans l'index approprié.

  L'ordre incorrect des interfaces routées dans une configuration de profil entraîne des problèmes de validation lorsqu'un utilisateur ajoute une route statique à l'aide de ces références pour cette interface routée.

• Problème résolu 108687 : Un utilisateur peut configurer une destination non-SD-WAN via une passerelle pour disposer de plusieurs passerelles avec la même adresse IP.

  Orchestrator doit rejeter cette configuration et renvoyer une erreur.

• Problème résolu 109125 : Sur la page Administration > Gestion des utilisateurs (User Management) de l'interface utilisateur d'Orchestrator, un utilisateur ne peut pas trier les clés SSH selon la colonne Durée (Duration).

  Cela limite la capacité d'un utilisateur à trouver une clé SSH particulière s'il tente de la localiser selon la durée de la clé.

• Problème résolu 109715 : Un lien WAN inactif ne s'affiche plus sur la page Surveiller (Monitor) > Présentation du réseau (Network Overview) au bout de 24 heures, même si la Limite de lien du dispositif Edge inactif (Edge Down Link Limit) est définie sur une valeur supérieure à 24 heures.

  Un utilisateur peut accéder à Clients et partenaires (Customers & Partners) > Surveiller les clients (Monitor Customers) > Paramètres de service (Service Settings) > Gestion des dispositifs Edge (Edge Management) et pour la section Paramètres généraux du dispositif Edge (General Edge Settings), la Limite de lien du dispositif Edge inactif (Edge Link Down Limit) peut être définie sur une valeur supérieure à 24 heures, puis enregistrée. Cependant, malgré ce nouveau paramètre, un lien WAN inactif n'est plus présent sur la page Surveiller (Monitor) après 24 heures.

• Problème résolu 110285 : Un utilisateur d'une entreprise cliente disposant de plus de 5 000 services réseau peut observer que l'interface utilisateur d'Orchestrator se charge lentement pour Présentation du réseau (Network Overview), Surveiller (Monitor) > Dispositifs Edge (Edges), Configurer (Configure)> Dispositifs Edge (Edges) et Configurer (Configure) > Dispositifs Edge (Edges) > Périphérique (Device).

  Ce problème est dû à l'appel d'API getEnterpriseServices qui demande beaucoup de temps pour extraire les résultats lorsqu'il existe un grand nombre de services réseau à récupérer.

• Problème résolu 111407 : VMware SASE Orchestrator n'autorise pas un utilisateur à désactiver l'interface routée d'un dispositif Edge si celle-ci est définie par l'utilisateur et si aucun lien WAN ne lui est associé.

   La validation d'Orchestrator ne permet pas à un utilisateur d'enregistrer des données sans ajout de lien WAN. La seule solution consiste à ajouter un lien WAN.

• Problème résolu 111497 : Sous la page Configurer (Configure) > Overlay Flow Control de l'interface utilisateur d'Orchestrator, les valeurs de Sorties VPN préférées (Preferred VPN Exits) s'affichent comme « non définies » pour les sous-réseaux de site.

  Si la configuration de next-hop est configurée pour une destination non-SD-WAN via une passerelle, les sous-réseaux du site dans Configurer (Configure) > Overlay Flow Control affichent Sorties VPN préférées (Preferred Exit VPN) comme « non définies » pour les VPN dont le type de tunnel est « ACTIVE_ACTIVE ».

• Problème résolu 111778 : Lorsqu'un utilisateur modifie une destination non-SD-WAN via une passerelle avec le type Point de contrôle (Checkpoint), Orchestrator remplace le type VPN par Routeur IKEv1 générique (Generic IKEv1 Router).

  Ce problème affecte les clients disposant d'une NSD de type Point de contrôle (Checkpoint) et peut entraîner une interruption si l'utilisateur ne détecte pas ce qu'effectue l'interface utilisateur d'Orchestrator.

• Problème résolu 112123 : Lorsqu'une instance de VMware SD-WAN Edge 640-N est ajoutée, l'interface utilisateur de VMware SASE Orchestrator affiche le nom du modèle de manière incorrecte.

  L'interface utilisateur d'Orchestrator affiche le nom « EdgeModel.edge640-n » et non « Edge 640-N ».

• Problème résolu 112188 : Pour une entreprise cliente qui déploie une destination non-SD-WAN à l'aide de GRE, Orchestrator affiche le message incorrect lorsque le tunnel NSD devient inactif.

  Orchestrator affiche le message suivant : « Tunnel IPsec direct du dispositif Edge inactif » (Edge Direct IPsec tunnel down), lorsque le tunnel NSD est GRE.

• Problème résolu 112535 : Lors de la configuration d'une règle de pare-feu sous Configurer (Configure) > Pare-feu (Firewall), l'écran Source > Définir (Define) > Transport affiche le port de transport de manière incorrecte.

  Orchestrator affiche l'option Port de transport comme étant simplement « Transport », ce qui est vague et peut entraîner une confusion lors de la configuration d'une règle de pare-feu.

• Problème résolu 112826 : Lorsqu'un client exporte une liste d'alertes vers un fichier CSV via l'interface utilisateur d'Orchestrator, il ne récupère que 512 éléments.

  Effectuer la même exportation à l'aide d'une API peut fournir jusqu'à 2 048 alertes, ce qui correspond également à la quantité attendue pour l'exportation de l'interface utilisateur d'Orchestrator. La limitation à 512 affecte les clients exportant des alertes lorsque le nombre d'alertes dépasse cette limite de 512 pour la période spécifiée.

• Problème résolu 113474 : L'utilisateur ne peut pas configurer une adresse d'interface d'hôte partielle lors de la configuration de la délégation de préfixe DHCPv6 sur des interfaces ou des sous-interfaces LAN IPv6.

  Orchestrator ne dispose pas d'une validation appropriée pour autoriser une adresse IPv6 partielle.

  Voici ce qui est attendu pour ce comportement : Avec le correctif, les types suivants d'adresses d'interface complètes ou partielles sont autorisés ou bloqués pour la délégation de préfixe DHCPv6 dans le LAN et le VLAN :

  • Adresses IPv6 autorisées :

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

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

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

    • ::f:1:0:f

    • ::f:1:e;

    • ::c:1

  • UNIQUE_LOCAL_IPV6 - fc00::

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

  • Adresses IPv6 bloquées :

    • Adresse vide - ::

    • Adresse multicast - FF01:0:0:0:0:0:0:18C, FF01:0:0:0:0:0:0:BAC0 ou FF01:0:0:0:0:DB8::

    • Loopback - 0:0:0:0:0:0:0:1 ou ::1

    • Local lien - fe80::210:5aff:feaa:20a2 ou fe80::260:97ff:fe02:6ea5

    • Local site - fec0::

  • Une seule paire de :: peut être utilisée, de sorte que les adresses IP suivantes sont bloquées : ::1:0:0::0:1 ou ::f:1:0::f

• Problème résolu 113530 : L'utilisateur ne peut pas remplacer le type d'adressage IPv6 Délégation de préfixe DHCPv6 (DHCPv6 Prefix Delegation) par un autre type sur une interface ou une sous-interface LAN routée.

  Dans la section Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) > Interface > Adresse IPv6 du LAN (LAN IPv6) dans laquelle la délégation de préfixe DHCPv6 peut être configurée sur Orchestrator, si l'utilisateur tente de sélectionner un autre type d'adressage (Statique (Static)/DHCP avec état (DHCP Stateful)/DHCP sans état (DHCP Stateless)), l'option Enregistrer (Save) reste inaccessible et l'utilisateur ne peut pas effectuer la modification. Ce problème est dû à un défaut dans un processus qui vérifie l'unicité de la configuration de la délégation de préfixe DHCPv6 dans un dispositif Edge.

• Problème résolu 114151 : Lorsque vous affichez des dispositifs Edge et des passerelles sur leurs pages de liste respectives, le certificat qui leur est attribué est une colonne facultative.

  L'utilisation de certificats étant un comportement par défaut, les ensembles de colonnes par défaut des listes Dispositif Edge (Edge) ou Passerelle (Gateway) doivent toujours les afficher sans demander à l'utilisateur de les définir.

• Problème résolu 114444 : Lorsqu'une instance de VMware SASE Orchestrator est mise à niveau vers la version 5.1.x ou une version ultérieure, un utilisateur ne peut pas enregistrer ses modifications de configuration pour une destination non-SD-WAN via une passerelle dans laquelle des tunnels redondants sont déjà configurés.

  L'utilisateur ne pourra pas enregistrer la configuration sur la page NSD via la passerelle (NSD via Gateway), ce qui peut entraîner des abandons de paquets sur les passerelles pour les NSD redondantes.

  La solution à ce problème consiste à mettre à jour le hop maximal sur 2 dans l'interface utilisateur NSD via la passerelle (NSD via Gateway) pour les BGP Neighbors redondants et à enregistrer les modifications.

• Problème résolu 114475 : Lorsqu'un opérateur tente de mettre à niveau un dispositif VMware SASE Orchestrator de la version 4.2.0 vers la version 5.1.0, Orchestrator peut signaler l'échec de la mise à niveau.

  Dans les journaux, l'opérateur observe cette entrée : Error while initializing CWS Server service Error: Too many connections. Ce problème est déclenché par le redémarrage de MySQL avant l'installation de vco-db-schema, ce qui est dû au fait que MySQL ne configure pas le nombre maximal de connexions. En outre, bien qu'Orchestrator signale l'échec de l'installation, cette dernière est en fait terminée et Orchestrator peut être redémarré. Tous les services fonctionneront alors comme prévu.

• Problème résolu 114897 : Lorsqu'il est connecté à l'interface utilisateur de VMware SASE Orchestrator en tant que partenaire ou lorsqu'un opérateur examine le niveau du partenaire, l'onglet « Clients » (Customers) s'affiche en tant que « Clients et partenaires » (Customers & Partners).

  Le nom correct est Clients (Customers) et s'affiche avec cette version d'Orchestrator.

• Problème résolu 115441 : Sur la page Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration), lors de la configuration de la vignette SD-WAN, les images logicielles et du microprogramme ne sont visibles que lorsqu'elles sont activées.

  Les images logicielles et du microprogramme doivent toujours être visibles par l'utilisateur, quel que soit leur état.

• Problème résolu 115695 : Sur la page Surveiller (Monitor) > Dispositifs Edge (Edges), un client ne peut pas rechercher un dispositif Edge par description dans le tableau Liste des dispositifs Edge (Edge List).

  Certains mots de la description d'un dispositif Edge (par exemple, Activé (Activated) ou l'emplacement du dispositif Edge) sont utiles pour rechercher tous les dispositifs Edge ayant une description semblable.

• Problème résolu 115837 : Sur la page Surveiller (Monitor) > Dispositifs Edge (Edges) ou Configurer (Configure) > Dispositifs Edge (Edges) de l'interface utilisateur d'Orchestrator, lorsque vous tentez de rechercher des dispositifs Edge dans la table principale, vous ne pouvez pas rechercher les dispositifs Edge tant que tous les dispositifs Edge ne sont pas chargés.

  Lors du chargement des dispositifs Edge sur la table principale, l'indicateur de liste bloque la barre de recherche, ce qui rend son utilisation impossible jusqu'à la fin de la demande, qui peut prendre un certain temps, en particulier si l'entreprise inclut un grand nombre de dispositifs Edge.

• Problème résolu 116021 : Sur la page Configurer (Configure) > Dispositifs Edge (Edges) > Détail du certificat (Certificate Detail) de l'interface utilisateur d'Orchestrator, la convivialité de la fenêtre de dialogue est médiocre.

  La fenêtre de dialogue Détail du certificat (Certificate Detail) comprend 3 barres de défilement intégrées, ce qui la rend très étroite et difficile à utiliser correctement.

• Problème résolu 116524 : Pour les clients qui s'abonnent à Edge Network Intelligence et sur lesquels l'analyse est activée, sur la page Surveiller (Monitor) lors de l'analyse de la liste de liens sur le côté gauche, un utilisateur observe deux liens pour l'analyse qui ont des noms différents, mais qui sont exactement identiques et redondants.

  Il existe deux liens pour Edge Network Intelligence : Analyse d'application (Application Analytics) et Analyse de site distant (Branch Analytics) et les deux sont au même emplacement dans ENI. Ce problème a été corrigé avec un lien unique sur le côté gauche appelé Edge Network Intelligence.

• Problème résolu 116610 : Les utilisateurs ne peuvent pas ajouter une nouvelle interface Loopback de dispositif Edge via APIv2.

  Impossible de créer une interface Loopback à l'aide de l'opération PATCH ADD via APIv2. La structure de schéma de l'interface Loopback dans APIv2 n'autorise pas les interfaces nommées par l'ID d'interface et, dans ce scénario, la mise à jour de l'interface Loopback échoue.

• Problème résolu 116999 : Lorsqu'un utilisateur opérateur se connecte à VMware SASE Orchestrator, sur le côté droit d'Orchestrator, le menu indique « Menu partenaire » (Partner Menu).

  Cela peut entraîner une confusion pour l'opérateur pensant qu'il accède au menu incorrect, car celui-ci devrait afficher « Menu de l'opérateur » (Operator Menu).

• Problème résolu 117001 : Sur la page Administration > Gestion des utilisateurs (User Management) > Rôles (Roles) de l'interface utilisateur d'Orchestrator, l'utilisateur ne peut pas observer tous les types de rôles/utilisateurs sur une seule page.

  La page Rôles (Roles) comporte une pagination, ce qui signifie que tous les rôles ne figurent pas sur une page de navigateur unique, mais qu'ils sont distribués sur plusieurs pages de navigateur. Le problème est que les contrôles de page de l'interface utilisateur ne sont pas facilement visibles et que le correctif élimine la pagination et place tous les rôles et types sur une seule page.

• Problème résolu 117020 : Sur la page Configurer (Configure) > Services réseau (Network Services) de l'interface utilisateur d'Orchestrator, si un utilisateur sélectionne l'onglet Services TACACS (TACACS Services) et tente de supprimer un service TACACS, l'interface utilisateur affiche la chaîne de texte incorrecte pour confirmer la suppression.

  Lors de la suppression d'un service TACACS, l'interface utilisateur affiche la chaîne de texte : configuration.networkServices.deleteConfirm. L'interface utilisateur doit afficher la boîte de dialogue de suppression correcte « Voulez-vous vraiment supprimer cet élément ? » (Are you sure you wish to delete this item?).

• Problème résolu 117145 : Pour une entreprise cliente qui déploie des VNF, lorsqu'un utilisateur modifie une configuration dans Configurer (Configure) > Périphérique (Device), Orchestrator désactive la VNF.

   Orchestrator ne redéploie pas la VNF après sa désactivation, ce qui entraîne une interruption significative pour un client.

• Problème résolu 117152 : Si un utilisateur crée un filtre BGP dans lequel la communauté a des valeurs entières supérieures à 65535 et l'attribue à un Neighbor, Orchestrator autorise cette intégration, même si le dispositif Edge ignore le filtre.

  Le dispositif Edge prend uniquement en charge les valeurs de communauté au format AA:NN avec les valeurs (0-65535):(0-65535). Si des valeurs supérieures à 65535 sont spécifiées sous forme d'entier, le dispositif Edge les ignore et Orchestrator ne parvient pas à rejeter un filtre dont la valeur est supérieure à 65535.

• Problème résolu 117385 : Un utilisateur peut observer une lenteur sur VMware SASE Orchestrator lorsqu'il tente de modifier plusieurs configurations.

  Le client ne peut pas effectuer plusieurs modifications de configuration sur Orchestrator, car chaque opération peut prendre jusqu'à une minute.

• Problème résolu 117537 : Sur la page Surveiller (Monitor) > Dispositifs Edge (Edges) > Sources de l'interface utilisateur d'Orchestrator, la liste Périphériques clients (Client Devices) affiche un nombre incorrect de périphériques, généralement un nombre inférieur au nombre réel.

  Ce problème se produit lorsque le mode « Visibilité par adresse IP » (Visibility by IP address) ou « Visibilité par adresse MAC » (Visibility by MAC Address) n'est pas défini sur le module de configuration spécifique du dispositif Edge par défaut, mais qu'il est défini dans un module associé.

• Problème résolu 117573 : Sur la page Configurer (Configure) > Périphérique (Device) > VPN > VPN cloud (Cloud VPN), lorsqu'un utilisateur tente de configurer un site distant vers Hub, les Hubs ne peuvent pas être filtrés à l'aide de l'icône de filtrage.

  Lorsqu'une entreprise cliente dispose de plusieurs Hubs configurés, l'absence de filtrage rend difficile la configuration d'un VPN site distant vers Hub.

• Problème résolu 117614 : Plusieurs actions sont manquantes dans la zone Raccourcis (Shortcuts) de la page Configurer (Configure) > Profil (Profile) de l'interface utilisateur d'Orchestrator.

  Les raccourcis manquants sont les suivants : Migrer le profil (Migrate profile), Dupliquer le profil (Duplicate Profile), Modifier le profil (Modify Profile) et Supprimer le profil (Delete Profile). Ces actions sont disponibles sur la page de liste du profil, mais le client devrait avoir un accès plus facile à ces actions.

• Problème résolu 118265 : Sur la page Gestion des utilisateurs (User Management) de l'interface utilisateur d'Orchestrator, un utilisateur Admin disposant des privilèges appropriés ne peut pas supprimer un compte d'utilisateur s'il a utilisé la recherche pour trouver ce compte.

  Lorsque l'utilisateur utilise la barre de recherche pour rechercher l'utilisateur et utilise au moins 4 caractères, une fois localisé le bouton Supprimer (Delete) est grisé et ne fonctionne pas.

• Problème résolu 118302 : Sur la page Surveiller (Monitor) > Dispositif Edge (Edge) de l'interface utilisateur d'Orchestrator, l'utilisateur ne peut pas filtrer l'état du lien pour les dispositifs Edge.

  L'API Orchestrator a été améliorée pour accepter l'état du lien en tant que paramètre de filtre et permet de filtrer l'état du lien sur l'écran de liste Dispositif Edge (Edge).

• Problème résolu 118527 : Sur une instance de VMware SASE Orchestrator déployée en tant qu'Orchestrator de bastion à l'aide d'une autorité de certification externe, les clients peuvent observer la mise hors ligne d'une instance VMware SD-WAN lors de sa promotion.

  Dans un environnement de bastion dans lequel le dispositif Orchestrator privé est intégré à une autorité de certification externe, le dispositif Edge passe à un état hors ligne peu après sa promotion sur le dispositif Orchestrator privé.

  Sur un dispositif Orchestrator sans correctif pour ce problème, la solution consiste à supprimer la liste de révocation des certificats (CRL, Certificate Revocation List) sur le périphérique Edge et à redémarrer le service Edge.

• Problème résolu 118670 : Le chargement de la page Surveiller (Monitor) > Services réseau (Network Services) > Clusters Edge (Edge Clusters) peut prendre plus de 30 secondes.

  Lorsqu'une entreprise dispose de plus de 10 000 services réseau, la page Surveiller (Monitor) > Services réseau (Network Services) > Cluster Edge (Edge Cluster) prend beaucoup de temps à se charger.

• Problème résolu 118761 : Sur la page Liste des dispositifs Edge (Edge Listing), lors de l'utilisation du menu déroulant Attribuer une image logicielle (Assign Software Image), l'utilisateur ne peut pas filtrer les images logicielles.

  L'absence de filtrage rend le processus de sélection plus difficile lorsqu'il existe de nombreuses images logicielles à sélectionner.

• Problème résolu 118764 : Sur la page Listes des dispositifs Edge (Edge Listings), la liste déroulante Attribuer un profil d'opérateur (Assign Operator Profile) n'autorise pas les utilisateurs à filtrer les éléments.

  L'absence d'options de filtre rend le processus de sélection du profil d'opérateur plus difficile qu'il ne devrait l'être.

• Problème résolu 118767 : Sur la page Présentation du dispositif Edge (Edge Overview), les utilisateurs ne peuvent pas filtrer les éléments et effectuer des sélections lors de la mise à jour de la sélection de licence Edge.

  L'absence de filtrage rend le processus de sélection plus difficile lorsqu'il existe un grand nombre de licences Edge pouvant être sélectionnées.

• Problème résolu 121336 : Lorsqu'un dispositif Edge ou un profil dispose de l'option « Attribution des passerelles de partenaires » (Partner Gateway Assignment) configurée sur la page Configurer (Configure) > Périphérique (Device) et que les modifications sont effectuées via un appel d'API, l'événement « Mise à jour du profil » (Profile Update) indique toujours que les passerelles sont supprimées.

  Il s'agit d'un problème superficiel n'ayant aucune incidence fonctionnelle. Ce problème se produit, car le champ Passerelles (Gateways) est obsolète dans la configuration.

• Problème résolu 121995 : Un client reçoit des alertes de basculement HA même s'il les a désactivées sur la page Configurer (Configure) > Alertes (Alerts) d'Orchestrator.

  Lorsque les alertes d'entreprise sont activées, mais que les alertes de basculement HA ne le sont pas, l'alerte de basculement HA est envoyée aux utilisateurs d'entreprise.

• Problème résolu 122940 : Lorsqu'un utilisateur se trouve sur la page Gestion des passerelles (Gateway Management), il peut être redirigé vers l'écran inapproprié dans certains cas.

  Lorsqu'un client souhaite attribuer une Passerelle VPN sécurisée (Secure VPN Gateway), Orchestrator doit la rediriger vers l'écran Attribuer une passerelle de centre de données (Assign Datacenter Gateway), mais il la redirige de manière incorrecte vers l'écran Attribuer une super passerelle (Assign Super Gateway).

• Problème résolu 123593 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité dans laquelle l'analyse Edge Network Intelligence est activée, dans de rares cas, le dispositif Edge HA peut ne pas extraire la configuration d'analyse du serveur principal Edge Network Intelligence.

  Il est possible que les dispositifs Edge actif et passif obtiennent le même jeton du serveur principal ENI. Si le dispositif Edge passif obtient le jeton après le dispositif Edge actif, le jeton du dispositif Edge actif devient obsolète, ce qui entraîne ce scénario.

• Problème résolu 123619 : Si un dispositif VMware SASE 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.

  Lorsqu'Orchestrator n'a pas accès à Internet, la page Présentation du dispositif Edge (Edge Overview) n'est pas accessible en raison d'une absence d'accès aux services Google.

• Problème résolu 123867 : Les mesures de lien et les API de série renvoient une erreur.

  Lorsque les mesures de lien ou l'API de série sont appelées sans liste de mesures, l'API renvoie par inadvertance une erreur au lieu d'ajouter toutes les mesures applicables à la réponse.

  Sur un dispositif Orchestrator sans correctif pour ce problème, un utilisateur doit envoyer une demande d'API avec une liste de champs de mesures à renvoyer.

• Problème résolu 124092 : Dans l'écran Overlay Flow Control, l'utilisateur ne peut pas voir le nom du segment.

  Lorsque vous tentez de filtrer le nom du segment, celui-ci ne fait pas partie des résultats.

• Problème résolu 124743 : Dans l'écran Surveiller (Monitor) > Dispositif Edge (Edge) > Présentation (Overview) de VMware SASE Orchestrator, le chargement de la grille État des liens (Links Status) ne se termine jamais.

  L'état des liens ne peut pas être chargé en raison de la configuration d'un ou de plusieurs liens WAN comme système de sauvegarde ou passif à chaud. Dans ce cas, un état Sauvegarde/passif à chaud (Backup/Hot Standby) est absent dans l'un des liens, ce qui entraîne l'échec de l'interface utilisateur.

  Un utilisateur peut résoudre ce problème en basculant le mode de lien pour le Transport de sauvegarde (Backup Transport) du lien de Passif à chaud (Hot Standby) à Actif (Active) et enregistrer, puis revenir à Passif à chaud (Hot Standby).

• Problème résolu 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.

• Problème résolu 127281 : Sous la page Configurer (Configure) > Overlay Flow Control de l'interface utilisateur d'Orchestrator, les configurations statiques sur les sous-interfaces routées ne s'affichent pas sur la page OFC comme routes connectées.

  Lorsqu'une configuration statique s'effectue sur une interface ou une sous-interface non-WAN routée, elles devraient s'afficher sur la page OFC comme routes connectées. Toutefois, cela ne fonctionne pas pour les sous-interfaces utilisant des configurations IPv6 dans lesquelles IPv6 n'est pas non plus activée sur l'interface parente de la sous-interface.

• Problème résolu 127636 : sur la page Surveiller (Monitor) > Dispositif Edge (Edge) > Sources de l'interface utilisateur de VMware SASE Orchestrator, la recherche d'une source par nom de domaine complet ne fonctionne pas.

  La fonctionnalité de recherche par nom de domaine complet ne fonctionne pas comme prévu dans la nouvelle interface utilisateur, ce qui empêche un utilisateur de trouver une source à l'aide d'une méthode standard. Il est donc impossible de lancer une recherche par chaîne partielle.

  Vous pouvez toujours effectuer une recherche par adresse IP, mais vous devez utiliser une chaîne complète.

• Problème résolu 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 problème empêche les utilisateurs d'afficher les certificats 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è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 75171 : Un utilisateur client du dispositif Edge ne reçoit pas d'adresse IP si le serveur DHCP est configuré sur un site de destination non-SD-WAN via une passerelle sur lequel le dispositif Edge fait office d'agent de relais.

  Ce problème est dû à l'abandon des messages Offre DHCP (DHCP Offer) par le dispositif Edge, car le code de ce dernier ne prend pas en compte cette configuration DHCP.

  Solution : Recherchez le serveur DHCP à un emplacement autre qu'une destination non-SD-WAN.

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

  Suite à la non-configuration des routes IPv6 et par défaut, les tunnels de gestion IPv6 de la passerelle AWS ne se forment pas et la passerelle ne fonctionne pas.

  Solution : Il n'existe aucune solution à ce problème. Évitez de déployer une passerelle avec propriétés mentionnées ci-dessus.

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

  Solution : Le client peut ignorer les événements de détection de boucle L2 des commutateurs en amont qui proviennent de l'interface HA du dispositif Edge (généralement GE1).

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

  Solution : 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 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 102583 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité avec des VNF installées, dans laquelle la paire de dispositifs Edge HA ou les modèles de dispositifs Edge 520/540 ou 610, l'accessibilité à la VNF du dispositif Edge passif à partir d'un client connecté au LAN peut échouer.

  La carte de commutateur Ethernet sur ces modèles d'Edge abandonne les paquets de réponse ARP envoyés à un client LAN à partir de la VNF d'un dispositif Edge passif, ce qui entraîne une perte d'accessibilité.

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

• 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 111592 : Pour une entreprise cliente utilisant une topologie Hub/Spoke dans laquelle les business policies sont configurées pour utiliser le backhaul Internet, le trafic Internet utilisant la règle de backhaul peut être lent ou ne pas fonctionner du tout.

  Dans certains cas, lors de la création du flux, la mise en correspondance de la business policy est modifiée en raison des informations d'inspection approfondie des paquets (DPI, Deep Packet Inspection) mises à jour. Cela peut entraîner la perte de l'ID logique du dispositif Hub Edge ou de la destination non-SD-WAN qui est censé effectuer le backhaul des paquets.

  Solution : Videz les flux pour forcer leur réinspection par le moteur DPI.

• 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 111840 : Sur une entreprise cliente déployée avec une topologie Hub/Spoke qui utilise au moins 9 dispositifs Hub Edge, les utilisateurs clients peuvent rencontrer une mauvaise qualité du trafic en raison d'un routage sous-optimal.

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

  Solution : Configurez d'abord les dispositifs Hub Edge, puis les Hubs VPN dans la liste de sites Site distant vers Hub.

• Problème 120309 : Les combinaisons de certains clients et serveurs VPN PPTP peuvent ne pas être en mesure de rétablir immédiatement une connexion après son interruption lors de l'utilisation de la NAT 1:1 lorsque l'Internet PPTP et le dispositif client se trouvent derrière le dispositif Edge. Ce problème a été confirmé avec le client Windows Server 2016 et Windows 10, mais peut également se produire avec d'autres versions.

  Ce problème est dû à l'utilisation par le serveur du même call-id PPTP pour la nouvelle connexion alors que le client utilise un nouveau call- id. Lorsque le call-id du serveur est réutilisé pour la nouvelle connexion, le pare-feu ne l'identifie pas comme une nouvelle connexion.

  Sur un dispositif Edge sans correctif pour ce problème, la solution consiste à vider la connexion PPTP périmée de la table NAT.

  Note:

  Le même problème peut se produire avec les emplacements réseau du client et du serveur échangés (en d'autres termes, le serveur PPTP se trouve sur le LAN derrière le dispositif Edge et le client se trouve sur Internet ou le cloud). Cette version du problème est suivie par le ticket n° 109830. Le correctif traite spécifiquement des clients Windows Server 2016. Les clients Windows 10 présentent toujours ce problème et ne sont pas concernés par ce correctif.

  Solution : Videz la connexion PPTP périmée de la table NAT.

• Problème 121281 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité, dans de rares cas, le client peut observer que le dispositif Edge passif a rencontré une panne du service de plan de données, généré un cœur et redémarré pour reprendre.

  Il y aura un événement sur le redémarrage du dispositif Edge passif et, si l'utilisateur configure une alerte d'échec HA, il en sera informé. Ce problème se produit dans de rares scénarios lorsqu'une route est synchronisée entre les dispositifs actif et passif et que le service Edge passif échoue en raison d'une corruption de la mémoire lors du traitement du message de synchronisation de la route.

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

• Problème 121371 : Pour une entreprise cliente configurée pour utiliser l'interconnexion du Hub ou du cluster dans laquelle le pare-feu avec état ou le pare-feu amélioré est également utilisé, les utilisateurs clients peuvent observer des abandons de trafic.

  Le routage asymétrique peut se produire entre les nœuds Hub des clusters source et de destination afin que le trafic sortant prenne un tunnel d'overlay direct, tandis que le trafic de retour prend une route d'underlay.

  Solution : La seule solution consiste à désactiver le pare-feu avec état ou les services de pare-feu améliorés.

• 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 PG 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 ne sont pas nécessaires, il peut être utile de les supprimer si cela permet de réduire leur nombre à moins de 64. Après une modification de la configuration, le service de passerelle doit être redémarré.

• Problème 121805 : Pour un dispositif VMware SD-WAN Edge déployé avec des VNF, l'utilisateur peut observer des réponses en double lorsqu'une VNF locale fait l'objet d'un test ping.

  Ce problème se produit lorsqu'un ping sur l'adresse IP d'une VNF s'effectue à partir du dispositif Edge.

  Solution : Exécutez toujours un ping à partir d'un client LAN derrière le dispositif Edge uniquement.

• 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 123379 : Pour un site d'entreprise client déployé avec une topologie à haute disponibilité, le client peut observer dans de rares cas une panne du service de plan de données du dispositif Edge passif et le redémarrage de celui-ci pour reprendre.

  Ce problème peut se produire lorsqu'un utilisateur tente de configurer une adresse IPv6 sur des sous-interfaces simultanément dans 128 segments à l'aide d'un script. Dans ce scénario, les configurations s'accumulent dans une file d'attente, ce qui entraîne l'échec du service du dispositif Edge passif.

  Solution : Il est recommandé de configurer les configurations d'adresses IPv6 sur les sous-interfaces dans des groupes plus petits afin que le système ait le temps de traiter et d'appliquer les configurations.

• Problème 125509 : Une entreprise cliente utilisant des modèles VMware SD-WAN Edge d'entrée de gamme peut rencontrer des bagotements pour BFD, BGP ou OSPF, en fonction du protocole de routage utilisé.

  Sur les plates-formes Edge d'entrée de gamme (510, 520, 540, 610 et 620) à une échelle de flux élevée et couplées à un routage dynamique et/ou à une configuration haute disponibilité, des bagotements de routage OSPF/BGP peuvent se bloque lorsque des temporisateurs d'intervalle Hello Timer et Dead Timer agressifs sont configurés. En outre, si le client utilise également Edge Network Intelligence avec l'analyse activée, le risque de rencontrer ce problème augmente.

  Solution : Si ce problème se produit, la solution consiste à rétablir les temporisateurs d'intervalle par défaut pour OSPF (10, 40) ou BGP (60, 180), ou à désactiver entièrement BFD.

• Problème 127920 : Une sonde ICMP associée à une route statique avec une adresse IP secondaire comme next-hop peut tomber en panne, même si l'adresse IP secondaire est active et accessible.

  Lorsqu'une sonde ICMP est associée à une route statique avec une adresse IP secondaire comme next-hop, la sonde fournit l'adresse IP de l'interface principale au lieu de l'adresse IP secondaire. Lorsque le peer ne parvient pas à atteindre l'adresse IP principale, la sonde ICMP tombe en panne, bien que l'adresse IP secondaire soit active et accessible.

  Solution : Il n'existe aucune solution dans ce scénario à part l'utilisation d'une adresse IP secondaire.

• Problème 128379 : Une route résumée BGP qu'un dispositif Spoke Edge annonce à un dispositif Hub Edge via un segment principal MPLS peut entrer dans une boucle de retrait et d'annonce.

  La séquence qui conduit à ce problème est la suivante :

  1. Le dispositif Spoke Edge ajoute son numéro de système autonome (ASN) et annonce le préfixe résumé BGP au routeur Edge (CE) du client. Ensuite, CE ajoute son ASN et l'annonce au dispositif Hub Edge.

  2. Le dispositif Hub Edge redistribue le préfixe résumé dans l'overlay (à l'aide du protocole de gestion SD-WAN VCRP) avec tous les ASN qu'il a reçus. Le dispositif Hub Edge redistribue également les préfixes qu'il a reçus sur le lien montant.

  3. Le dispositif Spoke Edge reçoit également le même préfixe résumé sur VCRP avec l'ASN de CE. Le dispositif Spoke Edge redistribue ce préfixe d'overlay dans BGP. Étant donné que la valeur as-set est activée dans la configuration de l'agrégation, BGP collecte les ASN à partir du préfixe d'overlay et les ajoute à la valeur AS_PATH du préfixe résumé.

  4. CE reçoit désormais le préfixe résumé avec la valeur AS_PATH mise à jour. Étant donné que l'ASN de CE fait partie de la valeur AS_PATH mise à jour, CE refuse le préfixe résumé et le retire du dispositif Hub Edge. Ce dernier le retire ensuite du dispositif Spoke Edge sur VCRP.

  5. À présent, le dispositif Spoke Edge redéfinit la valeur AS_PATH du préfixe résumé BGP sur Normal et l'annonce à nouveau. Ce cycle se répète indéfiniment.

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

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 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 114475 : Lorsqu'un opérateur tente de mettre à niveau un dispositif VMware SASE Orchestrator de la version 4.2.0 vers la version 5.1.0, Orchestrator peut signaler l'échec de la mise à niveau.

  Dans les journaux, l'opérateur observe cette entrée : Error while initializing CWS Server service Error: Too many connections.

  Ce problème est déclenché par le redémarrage de MySQL avant l'installation de vco-db-schema, ce qui est dû au fait que MySQL ne configure pas le nombre maximal de connexions. En outre, bien qu'Orchestrator signale l'échec de l'installation, cette dernière est en fait terminée et Orchestrator peut être redémarré. Tous les services fonctionneront alors comme prévu.

• 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 124568 : Pour un dispositif VMware SASE Orchestrator déployé avec une topologie de récupération d'urgence (DR), l'utilisateur opérateur peut observer dans de rares cas que la récupération d'urgence s'arrête, ce qui entraîne une absence de réplication temporaire entre les dispositifs Orchestrator actif et passif.

  L'expérience utilisateur n'est pas affectée, car elle est isolée de la récupération d'urgence uniquement. La page DR indique un état d'erreur au lieu de STANDBY_RUNNING.

  Solution : Il s'agit d'une erreur intermittente et la récupération s'effectue automatiquement.

• Problème 125006 : Pour un dispositif VMware SASE Orchestrator configuré avec une topologie de récupération d'urgence (DR), la base de données d'Orchestrator peut échouer, ce qui entraîne l'état d'erreur du dispositif Orchestrator passif. Dans de rares cas, cela peut entraîner l'affichage hors ligne des dispositifs Edge et des passerelles dans l'interface utilisateur d'Orchestrator et le déclenchement d'événements et d'alertes.

  L'état de la base de données doit se rétablir automatiquement en quelques minutes et les instances d'Orchestrator de récupération d'urgence se resynchronisent. Toutefois, cet état peut parfois dépasser la période de tolérance, et les dispositifs Edge et les passerelles commencent à envoyer leurs signaux de pulsation au dispositif Orchestrator passif plutôt qu'au dispositif Orchestrator actif. Par conséquent, le dispositif Orchestrator actif marque à la fois les dispositifs Edge et les passerelles qui ne lui envoient pas de signaux de pulsation comme étant inactifs et déclenche des événements et des alertes. Ce problème concerne uniquement la gestion et n'affecte pas le trafic réseau.

  Solution : Pour éviter ce problème sans correctif, il faut augmenter la propriété système Orchestrator qui régit la tolérance pour un échec de synchronisation : vco.disasterRecovery.transientErrorToleranceSecs d'une quantité appropriée pour fournir une fenêtre de récupération automatique plus longue.

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

  La nouvelle 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 de profil.

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

• 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 126695 : si un utilisateur configure des Webhooks pour des alertes, lorsqu'il clique sur le bouton Configurer le modèle de charge utile (Configure Payload Template), le menu ne s'affiche pas.

  Ce problème se produit lors de la configuration de Webhooks sur la page SD-WAN > Paramètres (Settings) > Alertes (Alerts) > Webhooks de l'interface utilisateur. Lorsqu'il examine la console du navigateur, un utilisateur observe également le message suivant : ERROR TypeError: Cannot read properties of undefined (reading 'invalid').

  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 ou 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 130115 : Pour un dispositif VMware SASE Orchestrator configuré avec une topologie de récupération d'urgence (DR), les pages DR des dispositifs Orchestrator actif et passif affichent des détails différents sous la section Historique (History).

  L'utilisateur voit des lignes supplémentaires pour un état de récupération d'urgence défaillant sur le dispositif Orchestrator actif par rapport aux lignes du dispositif passif sous la section Historique (History) et ces lignes ne sont pas triées par heure sur le dispositif Orchestrator actif.