This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

VMware SASE 5.1.0 | 18 décembre 2023

  • VMware SASE™ Orchestrator version R51010-20231215-GA

  • VMware SD-WAN™ Gateway version R5103-20230621-GA

  • VMware SD-WAN™ Edge version R5102-20230310-GA

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

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

Compatibilité

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

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

Orchestrator

Gateway

Dispositif Edge

Hub

Site distant/Spoke

5.1.0 

5.1.0 

3.4.5 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

3.4.6 

5.1.0 

5.1.0 

5.1.0 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.1.0 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

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

Attention:

Les versions 3.2.x, 3.3.x et 3.4.x de VMware SD-WAN ont atteint la fin du support.

  • Les versions 3.2.x et 3.3.x ont atteint la fin du support général (EOGS, End of General Support) le 15 décembre 2021 et la fin de l'assistance technique (EOTG, End of Technical Guidance) le 15 mars 2022.

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

  • La version 3.4.x d'Edge a atteint la fin du support (EOGS) le 31 décembre 2022 et la fin de l'assistance technique (EOTG) le 31 mars 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 3.x. (84151)

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

Note:

la version 3.x ne prenait pas correctement en charge AES-256-GCM, ce qui signifiait pour les clients utilisant AES-256 que GCM était toujours désactivé (AES-256-CBC) avec leurs dispositifs Edge. 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 ou 5.x. Une fois que tous ses dispositifs Edge exécutent une version 4.x/5.x, le client peut choisir entre AES-256-GCM et AES-256-CBC.

Chemins de mise à niveau pour Orchestrator, Gateway et Edge

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

Orchestrator

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

Gateway

La mise à niveau d'une passerelle Gateway à l'aide de la version 4.0.0 ou ultérieure vers une version 5.1.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.1.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.1.0 ou ultérieure.

Important:

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

Dispositif Edge

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

Nouvelles fonctionnalités de SD-WAN

Interconnexion du Hub ou du cluster (Hub or Cluster Interconnect)

Pour la première fois, plusieurs dispositifs Hub Edge ou clusters Hub peuvent être interconnectés sur la superposition plutôt que sur la sous-couche et augmenter la plage de dispositifs Spoke Edge pouvant communiquer entre eux. Les Hubs peuvent désormais partager des routes entre eux, ce qui permet aux dispositifs Spoke Edge connectés à un dispositif Hub Edge ou à un cluster Hub de communiquer via la superposition avec les dispositifs Spoke Edge connectés à un autre dispositif Edge Hub ou cluster Hub. Les dispositifs Spoke Edge dans un déploiement à Hubs multiples peuvent désormais utiliser l'optimisation dynamique des chemins multiples (DMPO) pour améliorer la qualité du trafic tout en offrant une visibilité complète de bout en bout de l'ensemble du trafic dans le réseau. L'interconnexion du Hub ou du cluster fournit à un client une évolutivité, une fiabilité et une disponibilité accrues dans son réseau de dispositifs Edge ou de clusters Hub multiples.

Important:

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

Nouvelle interface utilisateur d'Orchestrator

Orchestrator version 5.1.0 inclut l'implémentation complète de notre Nouvelle interface utilisateur qui a été introduite pour la première fois dans la version 4.0.0. La nouvelle interface utilisateur offre un aspect et une convivialité améliorés dans tous les services VMware SASE. En outre, la nouvelle interface utilisateur ajoute une aide intégrée au produit pour diriger les utilisateurs vers la documentation pertinente et d'autres documents qui peuvent vous aider à utiliser le service SD-WAN.

La nouvelle interface utilisateur est l'interface par défaut du dispositif Orchestrator 5.1.0, et l'utilisateur conserve l'option permettant de basculer vers l'interface utilisateur d'Orchestrator classique lors de l'utilisation de SD-WAN.

Note:

L'interface utilisateur classique sera obsolète dans la prochaine version mineure de VMware SASE Orchestrator. Les clients sont vivement encouragés à utiliser et à se familiariser avec la nouvelle interface utilisateur d'Orchestrator.

Visibilité du flux

Dans les versions précédentes, l'interface utilisateur d'Orchestrator affiche uniquement les informations et les statistiques de flux agrégées individuellement à partir de Application, Source ou Destination et ne combine pas toutes ces informations sur un écran pour fournir une vue unique de bout en bout. Par conséquent, la surveillance, le dépannage et les rapports sont entravés par le manque de visibilité détaillée de chaque flux.

Dans la version 5.1.0, la nouvelle interface utilisateur d'Orchestrator inclut un onglet « Flux » qui affiche les données consolidées pour chaque flux de trafic. L'interface utilisateur d'Orchestrator affiche les paramètres clés de chaque flux dans une vue unique. En outre, la fonctionnalité Visibilité du flux (Flow Visibility) permet aux clients de consulter les données de flux historiques, de filtrer les données en fonction des paramètres correspondants et de télécharger des statistiques de flux de bout en bout.

Entrées DNS locales

La version 5.1.0 prend en charge les entrées DNS locales sur le dispositif Edge pour pointer le trafic vers des domaines spécifiques. Lorsque le DNS local est configuré, le dispositif Edge recherche d'abord le fichier d'hôte local avant d'essayer de résoudre un domaine avec un serveur DNS.

Auto-test de mise sous tension (POST) pour Orchestrator, Gateway et Edge

La version 5.1.0 améliore la sécurisation renforcée et la visibilité des périphériques grâce à un autotest de mise sous tension (POST). POST est un processus exécuté par une routine logicielle appelée immédiatement après la mise sous tension ou le redémarrage d'un terminal, de façon automatique. Le processus POST inclut :

  • Vérification de l'intégrité du logiciel.

  • Vérification du test de réponse connue des algorithmes du module cryptographique.

  • Test de source d'entropie (bruit).

  • Affichage des résultats POST : Réussite/Échec (Pass/Fail). Le système continue d'installer le reste des applications uniquement si le résultat POST est Réussite (Pass). Si le résultat POST est Échec (Fail), des messages d'erreur s'affichent à l'endroit où le test a échoué et la séquence de démarrage du système s'arrête.

Pour les instances d'Orchestrator et les passerelles, cette fonctionnalité n'est disponible que dans un déploiement vierge. Cette fonctionnalité n'est pas activée par défaut sur les dispositifs Edge, et un utilisateur devra l'activer via l'interface utilisateur d'Orchestrator.

Nouvelles améliorations de SD-WAN

Synchronisation des routes locales haute disponibilité (HA) et Redémarrage normal de BGP

Pour un site déployé dans une topologie haute disponibilité dans laquelle BGP ou OSPF est également utilisé, un basculement HA peut être lent et perturbant pour le trafic client en raison d'une perte élevée de paquets lorsque le dispositif Edge passif synchronise les routes. Pour garantir des basculements HA plus rapides et moins perturbateurs, VMware ajoute deux améliorations : Synchronisation des routes locales HA (HA Local Route Synchronization) et Redémarrage normal de BGP (BGP Graceful Restart).

Synchronisation des routes locales HA (HA Local Route Synchronization) : synchronise automatiquement les routes entre les dispositifs Edge actif et passif et utilise ces routes pour le transfert sur le dispositif Edge actif, tout en garantissant également la disponibilité immédiate de la table de routage après un basculement HA.

Redémarrage normal de BGP (BGP Graceful Restart) : garantit des redémarrages et des basculements HA plus rapides du dispositif Edge en faisant participer les périphériques BGP avoisinants dans le redémarrage pour vérifier l'absence de modifications des routes dans le réseau pendant la durée du redémarrage. Sans redémarrage normal de BGP, le dispositif Edge peer supprime toutes les routes une fois la session TCP terminée entre les peers BGP. Ces routes doivent alors être recréées après le redémarrage ou le basculement HA du dispositif Edge. Le redémarrage normal de BGP modifie ce comportement en s'assurant que les dispositifs Edge peer ne suppriment pas les routes si une nouvelle session est établie dans un temporisateur de redémarrage configurable.

Important:

Pour optimiser les performances, le calcul du coût dynamique (DCC, Dynamic Cost Calculation) doit également être activé dans l'entreprise cliente. Lorsque le DCC est activé, les décisions de préférence et d'annonce sont locales pour le dispositif Edge et celui-ci passe du statut Actif (Active) à Passif (Standby) dès qu'il apprend les routes du processus de routage. Pour plus d'informations sur le DCC, reportez-vous aux sections Présentation du routage VMware SD-WAN et Configurer le calcul du coût distribué.

Note:

La synchronisation des routes locales HA n'est disponible que pour les entreprises utilisant BGP. La synchronisation des routes locales HA dans laquelle OSPF est utilisé sera disponible dans une version ultérieure.

Authentification RADIUS sur une interface commutée

Les clients peuvent utiliser l'authentification RADIUS à l'aide du protocole 802.1x sur les ports commutés, où ils étaient précédemment limités aux ports routés. L'authentification RADIUS des ports commutés est configurée via un VLAN associé à ce port. Cette amélioration convient aux sites clients sur lesquels aucun autre routeur n'est disponible pour étendre l'accès local, mais qui nécessitent une authentification de périphérique sécurisée via l'authentification 802.1x.

Contournement d'adresse MAC (MAB)

Sur les interfaces routées, les clients peuvent désormais vérifier les adresses MAC par rapport à une liste sur un serveur RADIUS pour contourner l'authentification 802.1x pour les périphériques LAN qui ne prennent pas en charge l'authentification 802.1x. L'association d'adresses MAC simplifie les opérations informatiques, économise du temps et améliore l'évolutivité en n'exigeant plus que les clients configurent manuellement chaque adresse MAC qui peut nécessiter une authentification.

Important:

Le MAB basé sur RADIUS n'est pas pris en charge pour les VLAN et ne peut donc pas être utilisé pour les ports commutés. Le MAB basé sur RADIUS n'est pris en charge que pour les interfaces routées.

Modifications de la configuration qui entraînent un redémarrage du dispositif Edge

Plusieurs modifications de configuration Edge qui ont précédemment déclenché un redémarrage du service Edge ne le font plus dans la version 5.1.0. En particulier, les modifications fréquemment utilisées de la configuration de l'interface Edge (telles que la modification d'une adresse IP LAN du dispositif Edge sur une interface commutée ou la modification d'une adresse IP CIDR, d'un préfixe CIDR ou d'une adresse IP fixe), n'entraînent plus de redémarrage perturbateur du dispositif Edge. Pour afficher la liste complète, consultez l'article de la base de connaissances Modifications de la configuration de VMware SD-WAN Edge pouvant déclencher un redémarrage du service Edge (60247).

SNMP

La version 5.1.0 ajoute les améliorations suivantes à SNMP :

  • SNMPv2, prise en charge de chaînes de communauté supplémentaires et de compteurs 64 bits.

  • SNMPv3, prise en charge de SHA2, noms d'utilisateur et mots de passe supplémentaires, et des clés privées et authentification distinctes.

  • La MIB ajoute la télémétrie suivante :

    • UUID de lien vers mappage de nom d'interface.

    • Bande passante/Capacité de liaison.

    • Débit de liaison.

Augmentation de la capacité de flux des dispositifs Edge 2000, 3800 et 3810

Les modèles d'Edge 2000, 3800 et 3810 augmentent chacun leur capacité de flux maximale de 1,9 million à 3,8 millions lors de l'utilisation du logiciel Edge de version 5.1.0.

Note:

Le modèle d'Edge 3400 n'est pas affecté par cette modification et la valeur maximale de la capacité de flux de ce modèle reste de 1,9 million de flux.

Capture de paquets (PCAP) sur les passerelles

Un utilisateur peut initier un PCAP sur une passerelle via l'interface utilisateur d'Orchestrator. Vous pouvez capturer jusqu'à 120 secondes le trafic de passerelle avec l'option pour définir des filtres simples ou complexes afin de s'assurer que l'utilisateur capture uniquement ce dont il a besoin. Cette fonctionnalité est accessible aux utilisateurs comme suit :

  • Les administrateurs partenaires peuvent initier un PCAP sur leurs propres passerelles de partenaires uniquement.

  • Les opérateurs peuvent initier un PCAP sur les passerelles de partenaires et les passerelles hébergées.

Autorité de certification externe (CA)

Deux nouveaux modes prêts pour l'API sont ajoutés à la fonctionnalité d'autorité de certification externe :

  • Le Mode manuel (Manual Mode) fournit la prise en charge de toute autorité de certification et offre une flexibilité et un contrôle avec l'utilisateur effectuant manuellement chaque étape du processus de certificat.

  • Le Mode asynchrone (Asynchronous Mode) fournit la prise en charge de toute autorité de certification avec la possibilité de créer un script pour les étapes manuelles et l'automatisation des tâches récurrentes.

Tunnels de destination non-SD-WAN (NSD) et du service de sécurité cloud (CSS)

Dans les versions précédentes de SD-WAN, les tunnels d'une NSD ou d'un CSS se formaient et se maintenaient uniquement lorsque le trafic passait par ceux-ci. En l'absence de trafic pendant un certain temps, le tunnel était démonté et devait être recréé lors du prochain envoi du trafic dans l'un des deux sens. Cela entraînait une latence pour ce trafic pendant le rétablissement du tunnel. À partir de la version 5.1.0, tous les tunnels NSD et CSS seront déclenchés et établis lors de la configuration initiale du service et se maintiendront, que le trafic passe ou non par ceux-ci pendant une période quelconque, ce qui améliore l'expérience utilisateur pour l'un des deux services.

Remarques importantes

Chaîne de communauté étendue BGP ajoutée aux préfixes BGP

Les routes BGP à l'intérieur du cluster sont automatiquement balisées avec une communauté BGP interne ajoutée aux communautés BGP existantes par chaque dispositif Edge. Cette chaîne de communauté supplémentaire combine 1 octet pour le nombre de tronçons et 3 octets provenant de l'ID logique du dispositif Edge. Par conséquent, les clients utilisant l'appairage BGP côté LAN du dispositif Spoke/Hub ne doivent pas filtrer les préfixes BGP annoncés par les dispositifs Edge avec la nouvelle chaîne de communautés BGP.

DPD (Dead Peer Timeout) pour les destinations non-SD-WAN

La version 5.1.0 apporte des modifications majeures à DPD (Dead Peer Timeout) pour les destinations non-SD-WAN. Dans les versions précédentes, la valeur par défaut de DPD était de 20 secondes et un utilisateur pouvait désactiver DPD en configurant le DPD Timeout Timer sur 0 seconde. Lors du transfert de VMware SD-WAN à QuickSec IPsec Toolkit, DPD change comme suit :

  • Intervalle d'analyse : Exponentiel (0,5 seconde, 1 seconde, 2 secondes, 4 secondes, 8 secondes et 16 secondes).

  • Intervalle DPD minimal par défaut : 47,5 secondes (QuickSec attend 16 secondes après la dernière nouvelle tentative. Par conséquent, 0,5+1+2+4+8+16+16 = 47,5).

  • Intervalle DPD minimal par défaut + DPD Timeout (secondes) : 67,5 secondes.

Suite aux modifications ci-dessus, un utilisateur ne peut pas désactiver DPD en configurant le DPD Timeout Timer sur 0 seconde. La valeur DPD Timeout en secondes est ajoutée à la valeur minimale par défaut de 47,5 secondes. Par conséquent, même si un utilisateur configurait DPD pendant 0 seconde, le DPD serait en réalité de 47,5.

Fonctionnalités qui doivent être configurées sur le dispositif Orchestrator classique

Dans la version 5.1.0, VMware fait de la nouvelle interface utilisateur l'interface d'Orchestrator par défaut en prenant en compte le fait qu'un utilisateur peut effectuer toutes les tâches de surveillance et de configuration sur celle-ci. Toutefois, certaines fonctionnalités ne sont pas entièrement intégrées à la nouvelle interface utilisateur :

  • Secure Access : paramètres du dispositif Edge et du profil

  • Zscaler (Zscaler) : paramètres du dispositif Edge et du profil

  • TACACS : page Paramètres du dispositif Edge et services réseau

  • Paramètres du partenaire : page partenaire

Pour configurer les fonctionnalités ci-dessus, un client peut sélectionner l'option Ouvrir Orchestrator classique (Open Classic Orchestrator) en haut de l'écran Orchestrator, ce qui ouvre un nouvel onglet de navigateur avec l'interface utilisateur classique.


Ces fonctionnalités seront entièrement intégrées à la nouvelle interface utilisateur dans une version ultérieure du logiciel Orchestrator.

Le mélange de dispositifs Edge compatibles Wi-Fi et non compatibles Wi-Fi en haute disponibilité n'est pas pris en charge 

À partir de 2021, VMware SD-WAN a ajouté des modèles d'Edge qui n'incluent aucun module Wi-Fi : modèles d'Edge 510N, 610N, 620N, 640N et 680N. Bien que ces modèles semblent identiques à leurs homologues compatibles Wi-Fi, à l'exception du Wi-Fi, le déploiement d'un dispositif Edge compatible Wi-Fi et d'un dispositif Edge non compatible Wi-Fi du même modèle (par exemple, un dispositif Edge 640 et un dispositif Edge 640N) comme paire haute disponibilité n'est pas pris en charge. Les clients doivent s'assurer que les dispositifs Edge déployés en tant que paire haute disponibilité sont du même type : compatibles Wi-Fi ou non compatibles Wi-Fi.

Modification du délimiteur de configuration du filtre BGPv4 pour l'ajout du préfixe AS-PATH

Dans la version 3.x, la configuration du filtre BGPv4 de VMware SD-WAN pour l'ajout du préfixe AS-PATH prenait en charge les délimiteurs basés sur les virgules et les espaces. À partir de la version 4.0.0, cependant, VMware SD-WAN ne prend en charge qu'un délimiteur basé sur les espaces dans une configuration d'ajout du préfixe AS-Path. Les clients qui mettent à niveau la version 3.x vers la version 4.x ou 5.x doivent modifier leurs configurations d'ajout du préfixe AS-PATH pour « remplacer les virgules par des espaces » avant la mise à niveau afin d'éviter une sélection incorrecte de la meilleure route BGP.

Durée de mise à niveau prolongée pour les modèles de dispositif Edge 3x00

Les mises à niveau vers cette version prendront plus de temps que la normale (3 à 5 minutes) sur les modèles de dispositif Edge 3x00 (c'est-à-dire, 3400, 3800 et 3810) si le dispositif Edge effectue directement une mise à niveau à partir de la version 4.0.0, 4.0.1 ou 4.2.0. Cela est dû à une mise à niveau du microprogramme qui résout le problème 53676. Un dispositif Edge 3400 ou 3800 est mis à niveau vers la version 5.1.0 à l'aide d'une autre version d'Edge. Le dispositif Edge se met à niveau comme prévu. Pour plus d'informations, consultez la section Problème résolu 53676 dans les notes de mise à jour correspondantes.

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

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

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

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

Cela est dû à chacun des modèles d'Edge répertoriés utilisant le contrôleur Ethernet Intel i350, qui présente une limitation selon laquelle lorsque la négociation automatique n'est pas utilisée des deux côtés de le lien, 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, le lien 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 le lien ne s'active pas avec un câble droit, un câble Ethernet croisé est nécessaire pour activer le lien.

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.1.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 de l'API Orchestrator depuis la version 5.0.0

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

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

Il est probable que les modifications suivantes nécessitent une action de la part des développeurs :

  • Problème n° 66795 : Ce correctif introduit un mécanisme au moyen duquel un jeton d'API sera uniquement valide et accepté par Orchestrator pour les utilisateurs non natifs s'ils sont à l'état activé (enabled) et si l'utilisateur SSO est actif dans son fournisseur d'identité respectif. Si un utilisateur non natif devient inactif (en d'autres termes, supprimé dans le fournisseur d'identité ou sans jeton d'actualisation valide), tous les jetons d'API de cet utilisateur seront révoqués via une tâche de serveur principal.

Note:

  • Les jetons émis pour le compte d'un utilisateur sur lequel SSO est activé avant ce correctif sont soumis à un comportement hérité dans lequel Orchestrator continuera à les respecter jusqu'à leur expiration.

  • Les utilisateurs SSO des fournisseurs d'identité qui ne prennent pas en charge les jetons d'actualisation ou le point de terminaison Introspection ne seront pas autorisés à utiliser la fonctionnalité d'authentification basée sur un jeton. 

  • Problème n° 87878 :vcoInventory/getPendingInventory a modifié la charge utile de réponse. Les champs suivants ont été supprimés : token, vcoInstanceLogicalId, vcoUrl, edgeMappingId, enterpriseId, enterpriseProxyId, uuid, mac, imei, owner. Ils ne sont pas utilisés sur le serveur frontal et cela n'affecte pas l'interface utilisateur, car ces champs n'ont pas été utilisés sur l'interface utilisateur. Cette API est destinée à être utilisée pour obtenir une liste des dispositifs Edge disponibles pour ZTP et ces champs ne sont pas requis pour l'attribution du dispositif Edge (seul serialNumber est requis). Par conséquent, si un client utilise cette API pour ZTP, il dispose d'une validation de charge utile stricte quelque part qui peut l'affecter (dépend de son implémentation). En général, les informations renvoyées sont suffisantes pour que le flux ZTP réussisse.

  • Problème no 84303 : Ajout d'une validation pour l'attribut BGP Neighbor maxHop pour ne pas autoriser la configuration d'une valeur maxHop inférieure à 2 lorsqu'un voisin localIP est présent. Auparavant, la configuration d'une valeur maxHop égale à 1 était autorisée, que le voisin localIP soit présent ou non. Et maintenant, conformément à la modification, lorsqu'un voisin localIP est présent, la valeur de tronçon Max-hop minimale autorisée est 2, et si un utilisateur tente de configurer une valeur maxHop inférieure à 2, il obtient une erreur indiquant Invalid MaxHop for Neighbor. MaxHop value ranges from 2 to 255 when localIp is present. Un correctif est en cours d'écriture pour prendre en charge la configuration existante.

  • Problème no 84114 : La migration de périphériques clients de MySQL vers ClickHouse a supprimé le champ clientDeviceId. Comme nous n'avons identifié aucun client externe à l'aide du champ clientDeviceId, l'incidence doit être négligeable. Le seul client utilisant le point de terminaison des périphériques clients avec clientDeviceId semble être l'interface utilisateur d'Orchestrator classique. L'interface utilisateur a été améliorée pour mettre à jour ou extraire des enregistrements dans ClickHouse à l'aide de la combinaison logicalId ou ipAddress et macAddress. Les clients externes doivent suivre la même procédure lors de l'utilisation du point de terminaison du périphérique client pour mettre à jour le nom d'hôte ou lors de l'extraction de périphériques spécifiques par ID.

Modifications de VMware SASE Orchestrator API v2

  • Problème no 98750 : Le champ lastContact dans l'enregistrement Edge renvoyé par les API liées au dispositif Edge est obsolète et ne doit plus être utilisé. Au lieu de cela, le champ edgeState dans la réponse doit être utilisé pour déterminer l'état réel du dispositif Edge en tant que source fiable unique. Si un code client utilise lastContact et ne peut pas le remplacer par edgeState, l'API v1 fournit toujours une valeur lastContact exacte dans la réponse, qui peut être utilisée comme compromis, bien que non recommandée.

  • Problème no 30901 : Dans la fonctionnalité Visibilité des flux (Flow Visibility) en place dans la version 5.1.0, la clause groupBy obligatoire n'est plus requise pour flowstats. Si la clause groupBy n'est pas mentionnée, nous considérons par défaut que le point de terminaison d'API interroge ou appelle le point de terminaison de l'API Visibilité des flux (Flow Visibility) qui, à son tour, est résolu pour tous les résolveurs tels que l'application, les périphériques clients, etc. Toutefois, cela s'applique uniquement à l'appel d'API de mesure des statistiques de flux, et l'API de la série de statistiques de flux demeure inchangée.

  • Problème no 95089 : Le module de limitation de débit APIv2 n'a pas appliqué la même stratégie par défaut que le limiteur de débit de l'API du portail, ce qui a toujours été notre intention. Une modification de cette version permet d'effectuer cette stratégie pour APIv2. Nous conseillons aux utilisateurs d'examiner les meilleures pratiques pour éviter de déclencher le limiteur de débit et de gérer les réponses dans le cas où la limitation de débit est déclenchée.

Remarque sur la documentation pour les développeurs

Traditionnellement, la documentation de l'API VMware SASE/SD-WAN était hébergée sur VMware {code} à l'adresse code.vmware.com. VMware {code} a été récemment migré vers un nouveau domaine, developer.vmware.com. Suite à la migration, certains liens permanents vers des pages spécifiques qui étaient précédemment hébergées sur code.vmware.com peuvent cesser de fonctionner comme prévu.

Conjointement à la migration, VMware continuer à utiliser le portail de documentation pour développeurs à l'adresse https://developer.vmware.com/apis, où se trouve désormais toute la documentation de l'API VMware SASE/SD-WAN.

Historique de révision du document

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

  • Ajout d'une nouvelle build cumulative R51010-20231215-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la dixième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.1.0.

  • La build R51010-20231215-GA d'Orchestrator inclut les correctifs des problèmes n° 117941, n° 125006, n° 128310, n° 129239 et n° 131789, qui sont documentés dans cette section.

9 octobre 2023. Vingt-troisième édition.

  • Ajout d'une nouvelle build cumulative R5109-20231003-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la neuvième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.1.0.

  • La build R5109-20231003-GA d'Orchestrator inclut les correctifs des problèmes n° 119938 et n° 128310, qui sont documentés dans cette section.

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

20 septembre 2023. Vingt-deuxième édition.

  • Ajout d'une nouvelle build cumulative R5108-20230916-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la huitième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.1.0.

  • La build R5108-20230916-GA d'Orchestrator inclut les correctifs des problèmes n° 94610, n° 104775, n° 105580, n° 106191, n° 115981, n° 116531, n° 117822, n° 118728, n° 121085, n° 121441, n° 121469, et n° 124778, chacun d'eux étant documenté dans cette section.

  • Déplacement du problème ouvert n° 62701 de Problèmes connus liés à Edge/Gateway vers les Problèmes résolus d'Edge/de Gateway sous la build GA R5100-20221204-GA d'origine. Cette action aurait dû être effectuée dans la 1re édition de ces Notes de mise à jour.

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

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

22 août 2023. Vingt et unième édition.

3 août 2023. Vingtième édition.

26 juillet 2023. Dix-neuvième édition.

  • Ajout du problème résolu n° 103708 à la section Problèmes résolus d'Edge/de Gateway pour la deuxième build cumulative R5102-20230310-GA. Ce problème a été omis dans la dixième édition des Notes de mise à jour de la version 5.0.1.

23 juillet 2023. Dix-huitième édition.

  • Ajout d'une nouvelle build cumulative R5107-20230722-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la septième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.1.0.

  • La build R5107-20230722-GA d'Orchestrator inclut un correctif du problème n° 122271, qui est documenté dans cette section.

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

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

15 juillet 2023. Dix-septième édition.

6 juillet 2023. Seizième édition.

  • Ajout d'une nouvelle build cumulative R5106-20230705-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la sixième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator par défaut pour la version 5.1.0.

  • La build R5106-20230705-GA d'Orchestrator inclut les correctifs des problèmes n° 84772, n° 115411, n° 115433, n° 116633, n° 117772, n° 117988, n° 117993, n° 118074, n° 118544, n° 118733, n° 119733 et n° 120606, qui sont documentés dans cette section.

  • Ajout du problème n° 95565 à la section Problèmes résolus d'Edge/de Gateway pour la build R5100-20221204-GA d'origine. Ce problème a été omis par erreur des Notes de mise à jour de la version 5.1.0 d'origine.

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

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

23 juin 2023. Quinzième édition.

  • Ajout d'une nouvelle build cumulative R5103-20230621-GA de Gateway à la section Problèmes résolus d'Edge/de Gateway. Il s'agit de la troisième build cumulative de Gateway et de la nouvelle build GA de Gateway pour la version 5.1.0.

  • La build R5103-20230621-GA de Gateway inclut les correctifs des problèmes n° 82808, n° 100172, n° 101536, n° 104619, n° 107309, n° 108473, n° 111646, n° 111888, n° 111924, n° 112016, n° 112017, n° 112019, n° 112020, n° 112800, n° 114052, n° 114084, n° 114282, n° 114932, n° 115604, n° 115692 et n° 116182, qui sont documentés dans cette section.

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

13 juin 2023. Quatorzième édition.

  • Ajout d'une nouvelle build cumulative R5105-20230611-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la cinquième build cumulative d'Orchestrator et de la nouvelle build GA d'Orchestrator pour la version 5.1.0.

  • La build R5105-20230611-GA d'Orchestrator inclut les correctifs pour les problèmes n° 87089, n° 105861, n° 106295, n° 107180, n° 107766, n° 110826, n° 111957, n° 112044, n° 112333, n° 112451, n° 112500, n° 112605, n° 112809, n° 112906, n° 112912, n° 112992, n° 113209, n° 113254, n° 113366, n° 113375, n° 113963, n° 114240, n° 114291, n° 114564, n° 114602, n° 114912, n° 115307, n° 115439, n° 115624, n° 115653, n° 115719, n° 116141, n° 116523, n° 116770, n° 116790, n° 116976, n° 117527, n° 117800, et n° 118071.

  • Ajout des problèmes ouverts suivants à la section Problèmes connus liés à Edge/Gateway : n° 82808, n° 107309, n° 111924, n° 112016, n° 112017, n° 112019, n° 114084, n° 114282, n° 115692 et n° 116182. Tous ces problèmes ont une incidence sur VMware SD-WAN Gateway.

11 mai 2023. Treizième édition.

  • Ajout des problèmes ouverts suivants à la section Problèmes connus liés à Edge/Gateway : n° 108473, n° 111646, n° 111888, n° 112020, n° 112800, n° 114052 et n° 114932. Tous ces problèmes ont une incidence sur VMware SD-WAN Gateway.

27 avril 2023. Douzième édition.

  • Ajout d'une nouvelle build cumulative R5104-20230426-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la quatrième build cumulative d'Orchestrator pour la version 5.1.0.

  • La build R5104-20230426-GA d'Orchestrator inclut les correctifs pour les problèmes n° 95631, n° 104785, n° 106327, n° 106929, n° 107071, n° 107349, n° 107980, n° 108072, n° 108363, n° 109284, n° 109300, n° 109532, n° 109533, n° 109715, n° 109788, n° 109836, n° 109911, n° 110094, n° 110330, n° 110946, n° 111104, n° 111407, n° 111444, n° 111665, n° 111934, n° 111944, n° 111946, n° 112094, n° 112201, n° 112224, n° 112437, n° 112458, n° 112885, et n° 114475. Chaque problème est documenté dans cette section.

  • Deux des tickets résolus, n° 106907 et n° 106929 ont été initialement marqués comme étant résolus dans Orchestrator version 5.1.0.2. Cependant, les correctifs étaient incomplets dans la version 5.1.0.2 et ne sont entièrement résolus que dans Orchestrator version 5.1.0.4. Par conséquent, ces tickets ont été supprimés de la section Problèmes résolus d'Orchestrator version 5.1.0.2 et déplacés vers la version 5.1.0.4.

  • Ajout du problème n° 94612 à la section Problèmes résolus d'Edge/de Gateway pour la build R5100-20221204-GA d'origine. Ce problème a été omis par erreur des Notes de mise à jour de la version 5.1.0 d'origine.

  • Mise à jour de la section Compatibilité pour marquer toutes les versions 3.x comme ayant atteint leur fin de cycle de vie (EOSL). Mise à jour également de la section 4.x pour marquer les dispositifs Orchestrator et les passerelles Gateway de version 4.2.x comme étant en fin de durée de vie du support (EOSL).

  • Ajout d'une Remarque importante intitulée Chaîne de communauté étendue BGP ajoutée aux préfixes BGP. Pour plus d'informations, reportez-vous à la remarque.

15 mars 2023. Onzième édition.

  • Ajout d'une nouvelle build cumulative R5103-20230315-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la troisième build cumulative d'Orchestrator pour la version 5.1.0.

  • La build R5103-20230315-GA d'Orchestrator inclut les correctifs des problèmes n° 107587, n° 107725, n° 108533, n° 108833, et n° 109064. Chaque problème est documenté dans cette section. R5104-202304xx-GA

14 mars 2023. Dixième édition.

  • Ajout d'une nouvelle build cumulative R5102-20230310-GA d'Edge et de Gateway à la section Problèmes résolus d'Edge/de Gateway. Il s'agit de la deuxième build cumulative d'Edge/de Gateway. Elle constitue la nouvelle build GA d'Edge et de Gateway pour la version 5.1.0.

  • La build R5102-20230310-GA d'Edge et de Gateway inclut les correctifs des problèmes n° 98782, n° 104141, n° 105744 et n° 106587, qui sont documentés dans cette section.

6 mars 2023. Neuvième édition.

  • Dans la section Nouvelles améliorations de SD-WAN, l'entrée Augmentation de la capacité de flux du dispositif Edge 3x00 a été révisée. L'entrée d'origine excluait le dispositif 2000 et incluait par erreur le dispositif Edge 3400. L'entrée révisée indique désormais :

    • Augmentation de la capacité de flux des dispositifs Edge 2000, 3800 et 3810

    • Les modèles d'Edge 2000, 3800 et 3810 augmentent chacun leur capacité de flux maximale de 1,9 million à 3,8 millions lors de l'utilisation du logiciel Edge de version 5.1.0.

    • Une remarque a été ajoutée pour indiquer clairement que le modèle d'Edge 3400 n'est pas affecté par cette modification et que la valeur maximale de la capacité de flux de ce modèle reste de 1,9 million de flux.

28 février 2023. Huitième édition.

  • Remplacement de la build cumulative R5102-20230216-GA d'Orchestrator par R5102-20230222-GA. La nouvelle build d'Orchestrator corrige un problème de mise à niveau détecté par l'équipe responsable des opérations VMware lors de la mise à niveau d'un dispositif Orchestrator vers la build R5102-20230216-GA. Le problème de mise à niveau est dû à une incompatibilité de version dans le manifeste du module de mise à niveau.

  • La nouvelle build inclut également des correctifs pour les problèmes suivants : N° 106907, n° 108074 et n° 108309.

17 février 2023. Septième édition.

  • Ajout d'une nouvelle build cumulative R5102-20230216-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la deuxième build cumulative d'Orchestrator pour la version 5.1.0.

  • La build R5102-20230216-GA d'Orchestrator inclut les correctifs pour les problèmes n° 40584, n° 105610, n° 106159, n° 106242, n° 106592, n° 106806, n° 106929, n° 107410, n° 107637, et n° 107885. Chaque problème est documenté dans cette section.

  • Ajout du problème n° 89725 à la section Problèmes résolus d'Edge/de Gateway pour la build R5100-20221204-GA d'origine. Ce problème a été omis par erreur des Notes de mise à jour de la version 5.1.0 d'origine.

  • Suppression du problème n° 39659 de la section Problèmes connus liés à Edge/Gateway, car il s'agit d'un doublon d'un autre ticket, n° 39501 qui a été résolu dans la version 4.3.0.

29 janvier 2023. Sixième édition.

  • Dans la section Compatibilité, la remarque relative à l'importation concernant la fin du support pour la version 4.2.x a été révisée et la version 4.3.x a été ajoutée pour indiquer les dates récemment révisées du logiciel SD-WAN Edge.

  • Dans la section Nouvelles améliorations de SD-WAN, l'amélioration Tunnels de destination non-SD-WAN (NSD) et du service de sécurité cloud (CSS) a été ajoutée. Elle a été omise par erreur dans la première édition des Notes de mise à jour.

  • Dans la section Remarques importantes, la remarque sur le Dead Peer Timeout (DPD) pour les destinations non-SD-WAN a été ajoutée. Cette remarque couvre les changements de comportement de DPD résultant de la modification logicielle de VMware SD-WAN dans QuickSec IPsec Toolkit. Cette ressource a été omise par erreur dans la première édition des Notes de mise à jour.

20 janvier 2023. Cinquième édition.

  • Ajout d'une nouvelle build cumulative R5101-20230112-GA de Gateway à la section Problèmes résolus d'Edge/de Gateway. Il s'agit de la première build cumulative de Gateway et de la nouvelle build Gateway GA pour la version 5.1.0.

  • La build R5101-20230112-GA de Gateway inclut les correctifs des problèmes n° 97272 et n° 104487, qui sont documentés dans cette section.

  • Modification de la langue de la fonctionnalité améliorée Contournement d'adresse MAC (MAB) (MAC Address Bypass [MAB]) pour indiquer clairement que cette fonctionnalité n'est pas prise en charge pour les VLAN et ne peut donc pas être utilisée pour les ports commutés, qui dépendent d'un VLAN pour l'authentification 802.1x. Le MAB est donc uniquement pris en charge sur les interfaces routées à partir de cette version 5.1.0.

12 janvier 2023. Quatrième édition.

  • Ajout d'un libellé concernant deux améliorations apportées à la version 5.1.0 : Synchronisation des routes locales HA (HA Local Route Synchronization) et Redémarrage normal de BGP (BGP Graceful Restart).

5 janvier 2023. Troisième édition.

  • Ajout d'une nouvelle build cumulative R5101-20221220-GA d'Orchestrator à la section Problèmes d'Orchestrator résolus. Il s'agit de la première build cumulative d'Orchestrator pour la version 5.1.0.

  • La build R5101-20221220-GA d'Orchestrator inclut les correctifs des problèmes n° 100133, n° 101835, n° 102806 et n° 103622,, qui sont documentés dans cette section.

15 décembre 2022. Deuxième édition.

  • Suppression du problème ouvert n° 39134 des problèmes connus liés à Edge/Gateway, car l'équipe d'ingénierie a conclu qu'il a été résolu et que ce ticket a déjà été ajouté par erreur aux problèmes résolus d'Edge/de Gateway dans la première édition des Notes de mise à jour de la version 5.1.0.

8 décembre 2022. Première édition.

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

Résolu dans Gateway version R5103-20230621-GA

La build R5103-20230621-GA de Gateway a été publiée le 23/06/2023 et constitue la 3e build cumulative de Gateway pour la version 5.1.0.

Cette build cumulative de Gateway résout les problèmes critiques ci-dessous depuis la 2e build cumulative R5102-20230310-GA de Gateway.

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

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

  • Problème résolu 100172 : si un utilisateur tente d'utiliser SSH pour se connecter à un dispositif Edge via une passerelle VMware SD-WAN Gateway, celle-ci peut subir une panne du service de plan de données et générer un vidage de mémoire suivi d'un redémarrage pour récupérer.

    La passerelle peut rencontrer ce problème lorsqu'un utilisateur tente d'utiliser SSH pour se connecter à un dispositif Edge via la passerelle, et la session SSH génère un message d'erreur FRAG_NEEDED ICMP.

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

    En examinant le fichier du noyau, l'utilisateur peut observer la journalisation liée au moniteur mutex de la passerelle qui peut se produire lorsque l'interconnexion du Hub et du cluster est utilisée par une entreprise cliente connectée à cette passerelle.

  • Problème résolu 104619 : Lorsque deux entreprises ou plus partagent la même passerelle partenaire et disposent toutes d'une configuration de transfert de partenaire dans laquelle les entreprises utilisent IPv4, si un transfert de partenaire dans une entreprise est supprimé, l'établissement de l'association de sécurité (SA) échoue pour les autres entreprises connectées à cette passerelle partenaire.

    Par exemple, s'il existe deux entreprises nommées Entreprise-1 et Entreprise-2 utilisant une passerelle de partenaires et qu'un transfert de partenaires est configuré sur les deux entreprises, le service SD-WAN définit une adresse IP unique dans l'interface réseau virtuelle de la passerelle. Si un utilisateur désactive le transfert de partenaires dans Entreprise-2, le service SD-WAN passe au flux suivant et supprime cette adresse IP de l'interface réseau virtuelle, même si la même adresse IP est utilisée pour le transfert d'Entreprise-1. Par conséquent, Entreprise-1 ne peut pas établir de tunnels IPsec avec ses dispositifs Edge.

    Si une passerelle rencontre ce problème sans correctif, le redémarrage de la passerelle permet de corriger le problème.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Problème résolu 114932 : Les utilisateurs clients d'un dispositif VMware SD-WAN Edge peuvent rencontrer une dégradation des performances du trafic traversant la passerelle VMware SD-WAN Gateway principale du dispositif Edge.

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

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

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

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

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

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

Résolu dans la version R5102-20230310-GA d'Edge et de Gateway

La build R5102-20230310-GA d'Edge et de Gateway a été publiée le 14/03/2023. Il s'agit de la 2e build cumulative d'Edge et de Gateway pour la version 5.1.0.

Cette build cumulative de Gateway résout les problèmes critiques ci-dessous depuis la première build cumulative R5101-20230112-GA d'Edge et de Gateway.

  • Problème résolu 98782 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données lors de l'établissement du tunnel IPsec, générant un cœur et redémarrant en conséquence.

    Lorsqu'une passerelle rencontre ce problème, le redémarrage peut entraîner une brève interruption du trafic client pour les deux dispositifs Edge connectés à cette passerelle et les destinations non-SD-WAN utilisant la passerelle pour les tunnels IPsec. Ce problème est dû à une condition de concurrence lorsque la passerelle qui établit un tunnel IPsec déclenche la panne du service de plan de données.

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

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

  • Problème résolu 104141 : Les utilisateurs derrière un dispositif VMware SD-WAN Edge ou les clients connectés à une passerelle VMware SD-WAN Gateway peuvent rencontrer des problèmes importants pour tout trafic qui utilise ce dispositif Edge ou traverse cette passerelle au point qu'aucun trafic ne peut être transféré.

    Lorsque ce problème se produit, le dispositif Edge ou la passerelle dispose d'un nombre illimité de mémoires tampons (mbufs) consommées par la file d'attente des tampons de gigue en raison de l'augmentation des horodatages du tunnel de gestion reçus par un peer. Cela déclenche un dépassement négatif d'entier dans le calcul de la gigue, qui entraîne une mise en tampon effective des paquets indéfinie. Au début, cela n'affecte que les flux mis en tampon, mais sur une période suffisamment longue, le nombre de mbufs consommés pour la file d'attente des tampons de gigue approche le nombre total de mbufs disponibles. Le périphérique SD-WAN (Edge ou gateway) peut devenir alors incapable de transférer entièrement tout le trafic. Si cela affecte une passerelle, cela a une incidence uniquement sur le trafic à chemins multiples qui traverse la passerelle et le trafic client direct n'est pas affecté.

    Un autre ticket n° 105744 traite également des symptômes trouvés ici, mais corrige une cause distincte. Différence entre les deux tickets : le correctif inclus dans n° 104141 corrige les mémoires tampons consommées par la file d'attente des tampons de gigue en raison de l'augmentation des horodatages de gestion reçus par le peer. Pour éviter que ce problème ne se reproduise, le correctif inclus dans n° 105744 limite le nombre de tampons de gigue à 25 % du nombre total de mémoires tampons quoi qu'il arrive.

    Sans correctif pour ce problème de dispositif Edge ou de passerelle, un utilisateur peut surveiller l'utilisation de la mémoire tampon (mbuf) sur Orchestrator et rechercher une utilisation accrue de mbuf en raison de la mise en file d'attente des paquets dans le tampon de gigue. Si l'utilisateur observe ce problème, il peut vider les flux du dispositif Edge (via Diagnostics à distance [Remote Diagnostics]) ou de la passerelle pour atténuer temporairement le problème, mais celui-ci se reproduit tôt ou tard tant que le correctif n'a pas été appliqué.

  • Problème résolu 105744 : Les utilisateurs derrière un dispositif VMware SD-WAN Edge ou les clients connectés à une passerelle VMware SD-WAN Gateway peuvent rencontrer des problèmes importants pour tout trafic qui utilise ce dispositif Edge ou traverse cette passerelle au point qu'aucun trafic ne peut être transféré.

    Ce ticket et le problème n° 104141 sont directement liés et présentent les mêmes symptômes et causes qui seront répétés ici : lorsque le problème se produit, le dispositif Edge ou la passerelle dispose d'un nombre illimité de mémoires tampons (mbufs) consommées par la file d'attente des tampons de gigue en raison de l'augmentation des horodatages du tunnel de gestion reçus par un peer. Cela déclenche un dépassement négatif d'entier dans le calcul de la gigue, qui entraîne une mise en tampon effective des paquets indéfinie. Au début, cela n'affecte que les flux mis en tampon, mais sur une période suffisamment longue, le nombre de mbufs consommés pour la file d'attente des tampons de gigue approche le nombre total de mbufs disponibles. Le périphérique SD-WAN (Edge ou gateway) peut devenir alors incapable de transférer entièrement tout le trafic. Si cela affecte une passerelle, cela a une incidence uniquement sur le trafic à chemins multiples qui traverse la passerelle et le trafic client direct n'est pas affecté.

    Différence entre les deux tickets : le correctif inclus dans n° 104141 corrige les mémoires tampons consommées par la file d'attente des tampons de gigue en raison de l'augmentation des horodatages de gestion reçus par le peer. Pour éviter que ce problème ne se reproduise, le correctif inclus dans n° 105744 limite le nombre de tampons de gigue à 25 % du nombre total de mémoires tampons.

    Sans correctif pour ce problème, le dispositif Edge ou la passerelle peut être surveillé sur Orchestrator dans lequel un utilisateur recherche une utilisation accrue de mbuf en raison de la mise en file d'attente des paquets dans le tampon de gigue et peut vider les flux du dispositif Edge ou de la passerelle afin d'atténuer temporairement le problème, mais celui-ci se reproduit tôt ou tard tant que le correctif n'a pas été appliqué.

  • Problème résolu 106587 : Un client peut observer l'abandon aléatoire de tout le trafic et la persistance de l'état.

    Le problème est lié à l'installation de l'association de sécurité (SA) IPsec côté répondeur. Lorsque le dispositif Edge initie une nouvelle SA ou effectue un renouvellement de clés, il est possible que le paquet SPI (Security Parameter Index) de l'ancienne SA arrive avant celui de la nouvelle SA (SPI). Dans ce cas, la passerelle VMware SD-WAN Gateway supprime la SA (SPI) qui vient d'être créée. Le correctif ajouté empêche la suppression de la nouvelle SA créée (SPI).

    Sans correctif pour ce problème, un utilisateur partenaire ou opérateur doit redémarrer la passerelle pour redémarrer tous les tunnels IPsec affectés.

Résolu dans la version R5101-20230112-GA de Gateway.

La build R5101-20230112-GA de Gateway a été publiée le 19/01/2023 et constitue la 1ère build cumulative de Gateway pour la version 5.1.0.

Cette build cumulative de Gateway résout les problèmes critiques ci-dessous depuis la build d'origine R5100-20221204-GA de Gateway.

  • Problème résolu 97272 : Sur un site disposant d'une topologie à haute disponibilité dans laquelle OSPF est utilisé, lorsque le site rencontre une condition split-brain (les deux dispositifs SD-WAN Edge sont actifs), la route par défaut vers le routeur principal est supprimée et le site HA ne peut pas accéder aux sites peer du réseau.

    L'ancienneté de l'annonce de l'état du lien (LSA) du routeur principal est synchronisée avec celle du dispositif Edge actif. En cas de condition de split-brain HA, le dispositif Edge passif passe à l'état actif et envoie une nouvelle ancienneté LSA au routeur principal. Étant donné que les dispositifs Edge actif et passif disposent du même ID de routeur, une ancienneté LSA différente est envoyée par le nouveau dispositif Edge actif. Cette discordance entraîne la définition de l'ancienneté LSA sur une valeur maximale de 3 600 dans le routeur principal. Cela supprime également la route principale vers le site HA, entraînant par la même une panne complète sur le site.

  • Problème résolu 104487 : En raison de la lenteur du service de base de données, les utilisateurs VMware SASE Orchestrator peuvent subir une lenteur globale et certaines pannes d'API. Les autres effets secondaires incluent les passerelles/dispositifs Edge SD-WAN qui s'affichent hors ligne dans l'interface utilisateur, les modifications de configuration apportées via l'interface utilisateur d'Orchestrator non transférées vers les dispositifs SD-WAN Edge cibles et une perte de capacités de génération de rapports.

    Ces problèmes sont tous dus à l'échec du service de base de données d'Orchestrator avec l'erreur : trop de fichiers ouverts. Cette erreur est constatée par l'opérateur VMware SASE Orchestrator via les journaux. Un utilisateur final accédant à VMware SASE Orchestrator via l'interface utilisateur subit une lenteur et des échecs intermittents de l'API, ce qui entraîne des messages d'erreur sur l'interface utilisateur.

Résolu dans la version R5100-20221204-GA d'Edge et de Gateway

La build R5100-20221204-GA d'Edge et de Gateway a été publiée le 08/12/2022 et résout les problèmes suivants depuis la build R5012-20221107-GA d'Edge et la build R5011-20221007-GA de Gateway.

Note:

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

  • Problème résolu 26085 : Un client utilisant une topologie Hub/Spoke et des passerelles de partenaires peut observer que le trafic est abandonné sur un dispositif VMware SD-WAN Spoke Edge si l'une des passerelles n'est pas configurée à partir d'un dispositif Hub Edge.

    Le trafic abandonné utilise une route périmée pour une passerelle qui n'est plus attribuée. Lorsqu'une passerelle n'est pas configurée à partir d'un dispositif Edge du Hub, elle ne sait pas que cela s'est produit et traite l'événement comme un simple événement d'arrêt de tunnel. Par conséquent, la passerelle continue de fournir au dispositif Spoke Edge sa route et le dispositif Spoke Edge ne supprime pas la route distante (accessible via le dispositif Hub Edge), car le dispositif Hub Edge est toujours accessible au dispositif Spoke Edge.

    Lorsque ce problème survient en l'absence d'une build corrigée, la seule façon de le corriger consiste à supprimer le lien Spoke Edge vers la passerelle.

  • Problème résolu 29929 : Pour un site déployé avec une topologie à haute disponibilité, en cas de basculement HA, un utilisateur peut ne pas être en mesure de se connecter à l'interface utilisateur locale pour les dispositifs Edge HA.

    Lorsque les informations d'identification locales sont modifiées pour les dispositifs Edge HA sur Orchestrator, le dispositif Edge actif approprié applique la modification, mais les nouvelles informations d'identification ne sont pas synchronisées avec le dispositif Edge en veille. Par conséquent, en cas de basculement HA et si le dispositif Edge en veille devient actif, le dispositif Edge utilise les informations d'identification (nom d'utilisateur et mot de passe) par défaut et un utilisateur tentant de se connecter à l'interface utilisateur locale échoue s'il utilise les informations d'identification les plus récentes.

  • Problème résolu 32413 : La température n'est pas incluse dans les statistiques de santé ou la MIB.

    Le correctif ajoute la température du CPU à la MIB utilisée pour SNMP et aux mesures affichées dans Surveiller (Monitor) > Dispositif Edge (Edge) > System (Système), également appelées « Statistiques de santé du dispositif Edge ».

  • Problème résolu 32654 : Les utilisateurs d'un site VMware SD-WAN Edge sur lequel une interface WAN est en panne peuvent observer une diminution du trafic.

    Le trafic diminue suite à l'annonce des routes connectées à une passerelle VMware SD-WAN Gateway, bien que l'accessibilité soit définie sur False sur le dispositif VMware SD-WAN Edge lorsque l'interface connectée est inactive.

  • Problème résolu 39134 : Lorsque vous examinez la page Surveiller (Monitor) > Dispositif Edge (Edge) > Système (System), le pourcentage de CPU n'est pas exact.

    Également appelé « Statistiques de santé du dispositif Edge », le dispositif VMware SASE Orchestrator ne reçoit pas d'informations précises sur l'utilisation du CPU Edge et les renvoie vers des graphiques sur la page système qui sont inexacts et erronés pour les clients qui tentent de résoudre un problème de dispositif Edge.

  • Problème résolu 45453 : Un client ne peut pas configurer un dispositif VMware SD-WAN Edge de sorte qu'il dispose de deux interfaces WAN utilisant le même VLAN.

    Ce problème se produit dans un scénario dans lequel un site connecte plusieurs ports WAN Edge au même commutateur L2 sur le même VLAN. Le problème avec cette configuration est que le dispositif Edge peut parfois utiliser une adresse MAC source incorrecte lors de l'envoi du trafic de gestion.

  • Problème résolu 50920 : VMware SD-WAN Edge n'envoie aucun avertissement lorsque le nombre de tunnels connectés atteint 60 % de la limite définie par le matériel pour ce modèle d'Edge.

    Le dispositif Edge envoie un avertissement lorsque le nombre de tunnels connectés atteint sa limite matérielle qui indique « Le nombre de tunnels établi dépasse la capacité de périphériques » (Established tunnel count exceeds the device capacity). Une fois cette limite atteinte, le dispositif Edge n'autorise pas de tunnels dynamiques supplémentaires tant que les tunnels existants ne sont pas désinstallés. Cependant, aucun avertissement intermédiaire n'est envoyé pour avertir le client que cette limite de tunnels est susceptible d'être atteinte. Le client ne dispose alors d'aucun délai adéquat pour gérer son réseau.

  • Problème résolu 53337 : Des abandons de paquets peuvent être observés avec une instance d'AWS d'une passerelle VMware SD-WAN Gateway lorsque le débit dépasse 3 200 Mbits/s.

    Lorsque le trafic dépasse un débit supérieur à 3 200 Mbits/s et une taille de paquet de 1 300 octets, les abandons de paquets sont observés à la réception (RX) et lors du transfert BH d'IPv4.

  • Problème résolu 54846 : Les bases MIB SNMP de VMware SD-WAN utilisent des compteurs pour la gigue, la latence et la perte de paquets.

    Dans les bases MIB SNMP de VMware, la latence, la gigue et la perte de paquets sont définies sur le compteur 64 qui n'est pas approprié pour ces types. Les compteurs doivent être utilisés pour les types de données qui sont des valeurs toujours croissantes et qui ne se réinitialisent jamais dans SNMP comme des octets Tx/Rx. Par contre, la latence, la gigue et la perte de paquets ne disposent pas de valeurs toujours croissantes, mais de valeurs ajustées dynamiquement alors qu'elles ne doivent pas utiliser de compteurs.

  • Problème résolu 55327 : La connexion SSH entre une passerelle VMware SD-WAN Gateway et un dispositif VMware SD-WAN Edge peut ne pas fonctionner en cas de bagotement continu du tunnel entre le dispositif Edge et la passerelle.

    Si c'est le cas, l'entrée de route installée dans le dispositif Edge pour autoriser la connexion SSH à partir de la passerelle peut être supprimée et provoquer l'échec de la connexion SSH.

  • Problème résolu 56153 : pour une entreprise cliente dans laquelle une destination non-SD-WAN via une passerelle est déployée et où BGP sur IPsec est utilisé, si un filtre BGP entrant n'est pas attribué par le client, le filtre n'est pas supprimé sur la passerelle VMware SD-WAN Gateway et la carte de route est appliquée avec celle-ci.

    Ce problème peut entraîner un routage inattendu pour le client, car il s'attend à ce que le filtre BGP entrant soit inactif, alors qu'il est toujours utilisé par la passerelle et le dispositif Edge.

  • Problème résolu 60844 : Une Business Policy conçue pour abandonner tout le trafic correspondant aux critères de la stratégie en configurant une limite de débit de 0 % ne fonctionne pas.

    Bien que la configuration d'une limite de débit de 0 % soit autorisée, le dispositif Edge ne s'affiche pas comme étant à 0 %, mais à 100 %, ce qui va totalement à l'encontre de l'objectif de la Business Policy.

    Sur un dispositif Edge sans correctif, la solution consiste à utiliser une règle de pare-feu pour faire correspondre et annuler le trafic par rapport à une Business Policy.

  • Problème résolu 61804 : Une entreprise cliente utilisant BGP peut observer que lorsqu'un dispositif VMware SD-WAN Edge apprend les routes d'un homologue, ces routes sont annoncées à l'homologue lui-même.

    Le dispositif Edge ne doit pas annoncer les routes apprises par les l'homologue à l'homologue lui-même. Cela entraîne un comportement de routage négatif et l'abandon du trafic.

  • Problème résolu 62701 : Pour un dispositif VMware SD-WAN Edge déployé dans le cadre d'un cluster Hub Edge, une mise à jour du plan de contrôle envoyée par Orchestrator peut entraîner le bagotement de tous les liens WAN sur le dispositif Hub Edge si le VPN cloud n'est pas activé sous le segment global, mais qu'il l'est sous un segment non global.

    Les liens WAN du dispositif Hub Edge qui se désactivent, puis s'activent rapidement (bagotement) ont une incidence sur le trafic en temps réel, tel que les appels vocaux. Ce problème était observé sur un déploiement client dans lequel le VPN cloud n'était pas activé sur le segment global du dispositif Hub Edge, mais où la configuration du cluster était activée. Ce dispositif Hub Edge faisait donc partie d'un cluster (et une configuration de cluster s'applique à tous les segments). Lorsqu'une modification de la configuration est transférée vers le dispositif Hub Edge, le plan de données de ce dispositif démarre l'analyse des données et commence par le segment global dans lequel il détecte le VPN cloud non activé. Le dispositif Hub Edge considère alors à tort que le clustering est désactivé sur ce segment global. Par conséquent, le dispositif Hub Edge démonte tous les tunnels du ou des liens WAN du Hub, ce qui entraîne des bagotements sur tous les liens WAN de ce dispositif Edge. Pour ce type d'incident, les liens WAN se désactivent et reprennent une seule fois uniquement par mise à jour du plan de contrôle.

    Sur une entreprise dans laquelle les dispositifs Edge n'utilisent pas de version avec un correctif pour ce problème, la solution consiste à activer le VPN cloud sur tous les segments, ce qui signifie le segment global et tous les segments non globaux.

  • Problème résolu 64526 : Lorsqu'un utilisateur modifie l'interface GE2 d'un dispositif VMware SD-WAN Edge de commuté à routé, puis configure une sous-interface sur cette interface et tente d'enregistrer les modifications, Orchestrator génère une erreur.

    Celle-ci est déclenchée uniquement lorsque la configuration de l'interface Edge est modifiée au niveau du profil (et non au niveau du dispositif Edge). L'erreur que l'utilisateur voit est « Type d'adressage inconnu DHCP_STATELESS pour la sous-interface GE2 – ignoré ». Celle-ci s'affiche sous la page Événements d'Orchestrator pour ce client.

  • Problème résolu 65530 : Un client déployant des SFP Metanoia sur un dispositif VMware SD-WAN Edge peut observer des problèmes avec le module.

    Ces problèmes peuvent survenir lorsque le client n'utilise pas un niveau plus récent de microprogramme mis à jour avec la version 5.1.0. Les modifications apportées à la version CSP et à la version du microprogramme SFP UPG sont indiquées dans le tableau ci-dessous :

    Version du dispositif Edge

    Version CSP

    Version du microprogramme SFP UPG

    5.1.0

    3.2.9.13

    1_62_8559

    4.0.0 - 5.0.x

    3.2.8.11

    1_62_8431

    Ces mises à jour garantissent une plus grande stabilité pour les SFP Metanoia sur le dispositif Edge.

  • Problème résolu 65919 : Pour un client qui a configuré un service de sécurité cloud (CSS) Zscaler, si le service Edge redémarre ou que le DNS est supprimé, le tunnel Zscaler peut échouer.

    Même si les requêtes DNS réussissent, le DNS n'affiche pas le nom de domaine complet Zscaler et le tunnel n'est donc pas actif. Lors de la vérification des journaux Edge pour le DNS, aucune entrée Zscaler ne figurera dans le cache DNS.

    Pour corriger le problème, un utilisateur doit effectuer un nslookup ou un test ping, après quoi l'entrée DNS est créée et le tunnel Zscaler s'active. 

  • Problème résolu 67900 : Une liaison WAN est configurée comme détectée automatiquement sur VMware SASE Orchestrator. Orchestrator peut la marquer comme liaison privée, même si elle doit être définie comme liaison publique.

    Orchestrator demande que la liaison soit définie comme privée, même si le client a défini la configuration de cette liaison comme publique. Cela peut entraîner des problèmes de connectivité importants avec une passerelle, car la liaison tentera de se connecter à une adresse IP privée et échouera dans le processus.

  • Problème résolu 68335 : Pour une entreprise cliente utilisant une topologie Hub/Spoke dans laquelle les Hubs sont des clusters, les dispositifs VMware SD-WAN Spoke Edge qui ne sont pas en mesure de se connecter à un cluster Hub risquent de consommer de grandes quantités de bande passante classée comme trafic de contrôle SD-WAN.

    Lorsqu'un dispositif Spoke Edge ne parvient pas à établir d'overlays avec ses clusters Hub du centre de données, le dispositif Edge demande aux contrôleurs de réattribuer un autre membre du cluster, ce qui entraîne l'envoi d'événements de contrôle continus et la consommation de bande passante des liens.

    Sur un dispositif Edge disposant du correctif, la solution à ce problème consiste à créer et à attribuer un profil temporaire, mais pas le cluster Hub inaccessible dans son profil.

  • Problème résolu 70248 : Lorsqu'une CRL est émise côté dispositif Edge, le tunnel tombe en panne et se rétablit.

    Lorsqu'Orchestrator révoque un certificat, par exemple un certificat de passerelle, le dispositif Edge met hors tension le tunnel, mais le rétablit de nouveau.

    Ce problème est lié à la durée de validité de la liste de révocation de certificats (CRL). Si la CRL dispose d'une heure de mise à jour antérieure à l'heure du dispositif Edge, le tunnel sera rétabli de nouveau.

    En l'absence de correctif, la seule solution consiste à s'assurer que les dispositifs Edge et Orchestrator disposent d'une correspondance de date et d'heure.

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

    Pendant le redémarrage du service Edge, le trafic client est interrompu pendant environ 15 à 30 secondes. Ce problème survient de manière incohérente, mais lorsqu'il se produit, le dispositif Edge désinstalle une association de sécurité IKE (SA). Généralement, cela a lieu uniquement lorsque le temporisateur SA (tel que configuré sur le dispositif VMware SD-WAN Orchestrator) expire ou que l'utilisateur modifie la configuration IPSec sur Orchestrator.

  • Problème résolu 71302 : Pour une entreprise cliente utilisant une destination non-SD-WAN via un dispositif Edge, le port utilisé est 500 au lieu de 4500.

    Ce comportement, qui n'est pas celui attendu, peut entraîner des problèmes avec le trafic utilisant cette NSD via le dispositif Edge si un autre périphérique bloque le port 500.

  • Problème résolu 71719 : La connexion PPTP n'est pas établie le long du chemin d'accès entre le dispositif Edge et le cloud.

    La connexion au serveur PPTP derrière le dispositif VMware SD-WAN Edge n'est pas établie.

  • Problème résolu 75553 : Un client déployant une destination non-SD-WAN (NSD) via une passerelle qui utilise un type basé sur la stratégie ne peut pas configurer des passerelles VMware SD-WAN Gateway redondantes.

    Dans les builds précédentes, VMware marque toujours une route NSD basée sur la stratégie comme « Accessible », quel que soit l'état, avec pour effet que la route de la passerelle principale de la NSD ne soit jamais marquée comme étant inaccessible et déclenche un basculement vers une passerelle redondante.

    Dans les versions 5.1.0 et ultérieures, le chemin de la passerelle est marqué comme accessible, sauf si la négociation IKE/IPsec échoue. À ce stade, il est marqué comme « inaccessible » et le trafic NSD traverse la passerelle redondante, comme il le fait avec une NSD basée sur une route.

  • Problème résolu 75668 : La balise DSCP est réinitialisée pour le trafic côté LAN lorsqu'elle est routée vers une destination LAN interne.

    Pour le trafic utilisateur routé/direct, le dispositif Edge réinitialise la balise DSCP sur 0 et la balise DSCP pour le trafic entrant et sortant sur le même dispositif Edge (en d'autres termes, reste local au dispositif Edge) est remplacée par un marquage CSP=0DSCP et est réinitialisée sur CS0 pour le trafic de sous-couche lorsqu'il traverse le dispositif Edge.

  • Problème résolu 76881 : Un dispositif VMware SD-WAN Edge peut subir des niveaux d'utilisation critiques de la mémoire lorsque plus de 10 000 baux DHCPv6 sont utilisés et peuvent potentiellement déclencher un redémarrage du service Edge.

    Un grand nombre de clients DHCPv6 sont connectés au serveur DHCPv6. Chaque client est fourni avec un bail et la mémoire du serveur DHCPv6 continue de croître. Le dispositif Edge ne limite pas le nombre de baux DHCPv6 pouvant être alloués, contrairement à la limite stricte de 5 000 adresses IPv4. Par conséquent, il est possible que le dispositif Edge alloue suffisamment de baux pour atteindre un niveau critique d'état de mémoire du dispositif Edge et déclencher un redémarrage du service.

    Le correctif du problème limite le nombre maximal de clients à 10 000.

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

    Ce problème est déclenché par une corruption de la mémoire de la passerelle causée par deux processus de passerelle qui gèrent respectivement les paquets de transmission et de réception en essayant d'accéder au même nœud dans une arborescence de recherche.

  • Problème résolu 77457 : Un utilisateur tente de générer une capture de paquets (PCAP) pour une interface sur un dispositif VMware SD-WAN Edge en veille. VMware SASE Orchestrator signale que le PCAP a échoué.

    Lorsqu'un utilisateur tente de générer un PCAP pour le dispositif Edge en veille dans un déploiement à haute disponibilité améliorée, l'interface utilisateur d'Orchestrator enregistre l'état de la demande comme Échec (Failed) et l'explication « Échec du téléchargement du bundle de diagnostics : ‘unicode' ne dispose pas de l'interface de mémoire tampon. » (Failed to upload diagnostic bundle: 'unicode' does not have the buffer interface.)


  • Problème résolu 77611 : Pour un site client utilisant une topologie à haute disponibilité, lorsque le dispositif Edge HA est migré vers un profil de configuration de différence, les deux dispositifs Edge peuvent passer à l'état Actif-Actif (Split Brain) et redémarrer en même temps pour récupérer.

    Pendant cet état Actif-Actif, les utilisateurs clients observent des problèmes importants de qualité de trafic liés à la perte de paquets.

    Ce problème est dû à l'échec des dispositifs Edge HA à suivre un processus lors du déplacement vers un nouveau profil dans lequel le dispositif Edge en veille doit d'abord redémarrer pour appliquer les modifications et rester en veille. Ensuite, le dispositif actif applique les modifications de configuration et redémarre, puis promeut uniquement l'instance en veille en mode actif lorsqu'elle est rétrogradée en veille. Au lieu de cela, le dispositif Edge en veille passe immédiatement à Actif après son redémarrage, ce qui entraîne l'état Actif-Actif.

  • Problème résolu 78037 : un dispositif VMware SD-WAN Edge peut rencontrer un pic d'utilisation de la mémoire suivi d'une panne du service de plan de données sur un serveur DHCPv6 configuré avec plus de 1 000 adresses.

    Le problème se produit pour les interfaces de route et commutées. Le problème peut se produire lorsque plus de 1 000 adresses sont configurées pour des clients sur un serveur DHCPv6. Lorsque plus de 1 000 clients obtiennent des adresses, la quantité de paquets de sollicitation DHCPv6 générés peut entraîner l'épuisement de la mémoire du dispositif Edge et la panne du service Edge.

  • Problème résolu 78050 : Un dispositif VMware SD-WAN Edge peut subir une panne du service de plan de données lorsqu'un serveur PPTP est présent côté LAN.

    En cas de présence du serveur PPTP côté LAN et de connexion d'un client PPTP d'Internet via une règle de pare-feu entrante, le service Edge peut tomber en panne en raison d'un échec de la recherche du canal de contrôle PPTP. Cette recherche est nécessaire pour garantir le renvoi du canal de données GRE à un client PPTP via le même lien.

    Sur un dispositif Edge utilisant une build sans correctif pour ce problème, la seule alternative d'un client consiste à ne pas utiliser de sessions PPTP.

  • Problème résolu 78435 : Un dispositif VMware SD-WAN Edge activé avec une URL via l'interface utilisateur locale peut générer une erreur indiquant que l'activation du dispositif Edge a échoué, alors qu'elle a réussi.

    L'activation de l'URL du dispositif Edge avec l'interface utilisateur locale génère l'erreur « L'activation du dispositif Edge n'a pas pu se terminer » (Edge activation could not be completed).


    Ce problème se produit, car le dispositif Edge fait référence à une demande d'activation plus ancienne avec des paramètres incorrects lors de la réponse à la demande d'état d'activation. Pendant ce temps, la demande d'activation actuelle avec les paramètres corrects est en cours de traitement. Par conséquent, l'interface utilisateur locale génère une erreur, même si l'activation du dispositif Edge est traitée correctement.

  • Problème résolu 79437 : Une passerelle VMware SD-WAN Gateway déployée sur un serveur à l'aide d'une carte réseau Intel X710 avec SR-IOV activé pour les interfaces peut échouer.

    Si cet échec se produit, l'opérateur observe que les interfaces X710 SR-IOV sont supprimées de DPDK et ne s'affichent pas lors de l'exécution de debug.py --dpdk_ports_d. En outre, /opt/vc/etc/dpdk.json n'affiche pas les interfaces SR-IOV. Le déploiement d'une passerelle Gateway vers la version 5.1.0 permet d'éviter ce problème.

  • Problème résolu 79338 : Lorsqu'un de nombreux clients DHCPv6 tentent d'extraire une nouvelle adresse IPv6, quelques clients peuvent ne pas être en mesure d'en obtenir une.

    Lorsque plus de 1 024 clients tentent d'acquérir une adresse IPv6 en même temps, certains clients peuvent ne pas obtenir d'adresse IPv6 valide. Ce problème se produit, car le cache du voisin est résolu et les entrées de voisin de quelques clients ne sont pas créées. Étant donné que toutes les entrées du voisin ne sont pas présentes, les messages de renouvellement échouent.

    Si un client n'utilise pas de build avec le correctif, il peut réessayer d'acquérir l'adresse IPv6 auprès des clients après quelques minutes.

  • Problème résolu 79550 : un dispositif VMware SD-WAN Gateway ou SD-WAN Edge peut subir une panne du service de plan de données et redémarrer.

    Ce problème peut se produire si un fragment de trafic de gestion répété (VCMP) est reçu, forçant le processus à écrire des données au-delà de la mémoire tampon allouée pour ce paquet, ce qui entraîne la panne.

  • Problème résolu 81881 : Une modification de la configuration du périphérique effectuée sur le dispositif VMware SASE Orchestrator peut ne pas être appliquée au dispositif VMware SD-WAN Edge ciblé, même si le dispositif Edge est connecté à Orchestrator.

    Le dispositif Edge peut également rencontrer ce problème sous une charge importante en cas de modifications fréquentes et rapides de la configuration. Dans ce scénario, le thread de gestion du dispositif Edge responsable de l'application de configuration se bloque et n'applique pas de modifications supplémentaires.

  • Problème résolu 81353 : Il est possible de voir une passerelle VMware SD-WAN Gateway déployée à l'aide d'une plate-forme Azure abandonner des paquets au niveau de la réception des interfaces.

    Les paquets sont abandonnés en raison d'une mémoire tampon faible. Le paramètre de tampon d'anneau ne fait pas partie des interfaces gérées non-DPDK utilisées par les plates-formes Azure, et les files d'attente de tampon d'anneau de réception de la carte réseau sont définies comme des nombres faibles.

  • Problème résolu 81355 : Les passerelles VMware SD-WAN Gateway déployées à l'aide de la plate-forme Azure peuvent rencontrer des problèmes avec des paquets d'une taille supérieure à 1 500 octets.

    Les paquets dont la taille est supérieure à 1 500 octets sont abandonnés avec le message d'erreur suivant : pkt_too_big_drop. Les paquets dont la taille dépasse largement 1 500 octets sont abandonnés avec le message d'erreur suivant : sock_too_big_dropp.

    Ce problème est dû au fait que la plate-forme Azure n'utilise pas d'interfaces liées à DPDK qui maintient la liste DPDK.json de la passerelle vide et les configurations réseau DPDK n'initialisent pas les paramètres TSO/GSO de l'interface Linux.

  • Problème résolu 81377 : Lorsque les sous-réseaux Secure Access sont mis à jour, les anciens sous-réseaux ne sont pas révoqués de BGP.

    Lorsqu'une configuration de sous-réseau Secure Access est modifiée, SD-WAN supprime uniquement les anciens sous-réseaux de la base d'informations de transfert (FIB) et d'autres tables de routage locales. Le problème est que SD-WAN ne révoque pas la route de la table BGP utilisée pour la redistribution et, par conséquent, ces routes obsolètes restent dans BGP.

  • Problème résolu 81483 : Pour un client disposant d'une topologie Hub-Spoke, si un utilisateur augmente les durées de vie IKE et/ou IPsec via VMware SASE Orchestrator, le client peut remarquer que certains tunnels conservent les anciennes durées de vie. De ce fait, certains tunnels effectuent des renouvellements de clés plus fréquemment que prévu, car ils ont conservé les durées de vie précédentes.

    Si le client diminue les durées de vie, il rencontre techniquement ce bogue (une extrémité de la technologie Hub-Spoke peut conserver l'ancienne durée de vie supérieure), mais ne remarque aucune différence de fonctionnalité, car le dispositif Edge qui a correctement reçu la durée de vie inférieure effectue d'abord les renouvellements de clés, ce qui masque le problème.

    La seule solution à ce problème consiste à modifier les valeurs de durée de vie jusqu'à ce que tous les tunnels reflètent l'état correct, puis à redémarrer le dispositif Edge.

  • Problème résolu 82104 : Dans de rares cas, les dispositifs VMware SD-WAN Edge activés dans une topologie à haute disponibilité peuvent ne pas être en mesure de communiquer avec un dispositif VMware SASE Orchestrator qui marque le site comme étant inactif et empêche toute intervention sur le site via Orchestrator.

    Ce problème se produit uniquement lorsqu'une configuration inhabituelle et non valide est appliquée aux dispositifs Edge HA. La configuration spécifie que le port HA est configuré en tant que « trunk » (qui ne doit pas être autorisé), sans VLAN (ne doit pas non plus être autorisé), mais lorsque « tous les VLAN » sont définis. Au lieu de générer une erreur au niveau de cette configuration et d'empêcher un utilisateur d'activer HA pour les dispositifs Edge, Orchestrator l'autorise. Cette configuration autorisée déclenche une panne du plan de gestion sur les dispositifs Edge HA qui n'envoie plus de pulsation à Orchestrator. Le correctif ici permet le fonctionnement de cette configuration non valide sur une paire de dispositifs Edge HA sans interrompre le trafic de gestion vers Orchestrator.

  • Problème résolu 82188 : Pour les modèles VMware SD-WAN LTE (Edge 510-LTE, 610-LTE), lorsque le paramètre IPv6 est désactivé, les tunnels via l'interface CELL risquent d'échouer.

    Lorsque la case IPv6 dans Paramètres du périphérique (Device Settings) est désactivée, l'état interne de l'interface CELL passe à INCONNU (UNKNOWN). Cette fonctionnalité n'est pas mise à jour, même lorsque le paramètre IPv6 est activé pour l'interface CELL. De ce fait, les tunnels via l'interface CELL échouent. Si le dispositif Edge LTE utilise uniquement des interfaces CELL pour le trafic, cela entraîne la déconnexion du dispositif Edge et l'abandon de tout le trafic du dispositif Edge, ce qui est très perturbateur pour le client.

    Sans le correctif, un utilisateur doit redémarrer le service Edge après avoir désactivé le paramètre IPv6. Si le dispositif Edge est hors ligne, car il n'utilise que l'interface CELL pour la bande passante, un utilisateur local doit effectuer un cycle d'alimentation du dispositif Edge pour le récupérer.

  • Problème résolu 83040 : Une entreprise cliente disposant d'une topologie Hub/Spoke qui utilise des passerelles de partenaires et une destination non-SD-WAN (NSD) peut observer que le trafic qui devrait utiliser une NSD opte plutôt pour un Hub.

    Le dispositif Spoke Edge dispose d'une Business Policy qui effectue un backhaul du trafic vers la NSD. Si un transfert de la passerelle partenaire est également configuré pour lui, le dispositif Spoke envoie alors le trafic qui doit utiliser une NSD plutôt que le dispositif Hub Edge. Le Hub envoie à son tour le trafic directement à Internet. Si le transfert de la passerelle partenaire est désactivé, ce trafic NSD est routé correctement.

  • Problème résolu 83227 : Pour un dispositif VMware SD-WAN Edge exécutant la version 5.0.0 qui est configurée avec 128 segments, le processus dnsmasq du dispositif Edge s'arrête et se ferme.

    Lorsque IPv6 est activé sur 128 segments et que des serveurs DCPv6 sont configurés dans le LAN de chaque segment, le processus dnsmasq s'arrête lorsque le nombre total de descripteurs de fichiers ouverts est dépassé. Le processus dnsmasq continuera pendant environ 30 minutes avant de se fermer, auquel cas l'attribution DHCP des adresses IP du dispositif Edge échoue.

    Le redémarrage du dispositif Edge restaure le processus dnsmasq pendant environ 30 minutes, mais il échoue à nouveau. La seule solution réelle consiste à réduire le nombre de segments à moins de 128.

  • Problème résolu 83821 : Pour les clients qui utilisent NetFlow, les paquets/octets de transmission et de réception pour le trafic de contrôle SD-WAN ne sont pas mis à jour correctement dans les enregistrements NetFlow.

    Les données de contrôle SD-WAN (paquets/octets de transmission et de réception) qui sont exportées vers un collecteur NetFlow sont toujours égales à zéro. Comme les entrées ne sont pas renseignées dans le chat_stats du conteneur de flux, NetFlow n'exporte pas non plus les données.

  • Problème résolu 84000 : Une passerelle VMware SD-WAN Gateway connectée à des dispositifs Edge déployés dans une configuration à double pile (IPv4/IPv6) où la fréquence de démontages de tunnels et de liaisons avec les dispositifs Edge est élevée peut subir une fuite de mémoire qui, si elle est suffisamment importante, déclenche un redémarrage du service.

    Lorsqu'un tunnel VCMP (gestion chiffrée) est créé et supprimé plusieurs fois pour un dispositif Edge avec une configuration à double pile, cela peut donner l'apparence d'une fuite PI dans la passerelle de ce dispositif Edge si la passerelle fonctionne à grande échelle. Cette fuite PI n'est pas réelle, mais la suppression de PI se produit lentement et ce taux de suppression lent peut entraîner des problèmes de mémoire partagée susceptibles de devenir critiques.

    Sur une passerelle sans correctif, un redémarrage du service efface temporairement la mémoire.

  • Problème résolu 84136 : Le client peut observer une utilisation élevée du CPU et des performances de trafic médiocres sur un dispositif VMware SD-WAN Edge mis à niveau vers certaines versions d'Edge.

    Ce problème se produit sur un dispositif Edge sur lequel plus de 400 règles IP sont configurées sous la section Configurer (Configure) > Pare-feu (Firewall) > Accès au dispositif Edge (Edge Access) (Adresses IP autorisées de l'accès au support ou de l'accès SNMP). Lorsque le dispositif Edge tente d'envoyer la configuration du pare-feu dans ce scénario, le processus de gestion sature le CPU et il expire. Puis ce processus se répète.

    Sur les sites clients qui utilisent également une topologie à haute disponibilité, les symptômes incluent des « événements HA inconnus », car le dispositif Edge actif n'envoie pas de pulsations dans la fenêtre de temps prévue.

  • Problème résolu 84225 : Lorsqu'une interface VMware SD-WAN Edge connectée tombe en panne, le sous-réseau configuré est toujours redistribué à OSPF ou BGP.

    Le dispositif Edge attire le trafic de l'homologue pour le sous-réseau lorsqu'il est inactif et peut provoquer des interruptions de trafic dues à l'homologue préférant ce chemin à d'autres alternatives vers le sous-réseau.

    Sur un dispositif Edge sans correctif pour ce problème, l'utilisateur doit redémarrer le dispositif Edge dans une fenêtre de service planifiée pour résoudre le problème.

  • Problème résolu 84313 : Sur une entreprise cliente disposant d'une topologie Hub/Spoke, une liaison de superposition IPv6 peut être annoncée aux homologues de sous-couche des dispositifs VMware SD-WAN Spoke Edge.

    Lors de la configuration d'une adresse IPv6 sur la superposition et de l'activation de l'annonce, la même adresse est également annoncée via la sous-couche.

  • Problème résolu 84741 : Un utilisateur observe des statistiques de débit inexactes sur les écrans Surveiller (Monitor) > Transport.

    Les statistiques des liens et des paquets reçus (entrants) ne sont pas incrémentées dans Orchestrator pour le trafic envoyé directement sur une interface sur laquelle Reverse Path Forwarding (RPF) est désactivé sur l'overlay WAN.

  • Problème résolu 84790 : Lorsqu'un dispositif VMware SD-WAN Edge disposant d'un type de modèle autre que 510/510-LTE est redémarré, il peut signaler par erreur l'événement critique Unable to launch service wifihang au dispositif VMware SASE Orchestrator.

    Le message d'événement wifihang est conçu pour être utilisé uniquement avec les modèles d'Edge 510/510-LTE et avertit le client d'un problème lié au processus Wi-Fi de ce modèle d'Edge. Lorsque ce message d'événement s'observe sur un autre modèle d'Edge, que celui-ci utilise ou non le Wi-Fi (par exemple : le dispositif Edge 3400), le message d'événement est infondé et peut être ignoré sans problème.

  • Problème résolu 85154 : Lorsqu'un dispositif virtuel VMware SD-WAN Edge sur AWS avec le type d'instance C4.xlarge est mis à niveau d'une version antérieure d'Edge vers une version plus récente (y compris la version 4.3.1), puis rétrogradé vers une version antérieure d'Edge, le dispositif Edge passe à un état désactivé dans lequel le dispositif Edge ne forme pas de tunnels de gestion avec Gateway et Orchestrator.

    Ce problème est dû au fait qu'Orchestrator désactive par erreur le dispositif Edge en raison de ce qu'Orchestrator détecte comme une incompatibilité de numéro de série.

    Il n'existe aucune solution à ce problème, sauf ne PAS effectuer de rétrogradation à partir de la version d'Edge la plus récente une fois que le dispositif Edge AWS utilise cette version.

  • Problème résolu 85156 : Pour un site déployé avec une topologie à haute disponibilité, le client peut observer plusieurs redémarrages du dispositif VMware SD-WAN Edge passif avec une interruption potentielle du trafic client.

    La logique de traitement de synchronisation des données de contrôle HA sur le dispositif Edge passif pour les données reçues via TCP peut entraîner une lecture partielle des données uniquement. Cela peut provoquer le traitement de plusieurs messages courts de ce type sur le dispositif passif, ce qui peut ralentir le nœud passif. Dans les plates-formes Edge bas de gamme (par exemple, les modèles d'Edge 510, 520, 610 et 620), ce ralentissement peut avoir une incidence significative sur le traitement des pulsations entre les dispositifs actif et passif, ce qui entraîne une promotion incorrecte du dispositif Edge passif en mode actif. Dans un état Actif-Actif, la situation tourne à l'avantage du dispositif Edge actif et le dispositif Edge passif est redémarré pour le rétrograder à son état passif approprié.

    Lorsque ce problème se produit sur une topologie HA conventionnelle, l'incidence sur le client est minime, car le dispositif Edge passif ne transmet pas le trafic client. Sur un déploiement HA amélioré, dans lequel le dispositif Edge passif transmet également le trafic, le ou les redémarrages interrompent certains trafics client. 

    Le correctif de ce problème ajoute des améliorations dans la logique de traitement des messages TCP du dispositif Edge pour améliorer les performances sur le dispositif Edge passif et éviter un ralentissement du système.

  • Problème résolu 85269 : Pour les entreprises clientes utilisant une topologie Hub/Spoke dans laquelle la fonctionnalité multicast est configurée, un récepteur multicast peut ne pas recevoir la source de trafic derrière un dispositif Hub Edge où l'adresse IP source est définie manuellement sur le dispositif Hub Edge ou sur un dispositif Spoke Edge, mais pas sur les deux.

    Les journaux Pimd et les commandes de débogage fournissent aux utilisateurs la confirmation si l'envoi de la jonction PIM échoue en raison d'une incompatibilité entre une adresse IP de voisin PIM et une adresse IP de tronçon suivant, empêchant ainsi LHR d'atteindre le RP et l'enregistrement (*,G).

  • Problème résolu 86098 : Pour un site utilisant une topologie à haute disponibilité améliorée dans laquelle un lien WAN PPPoE est utilisé sur le dispositif Edge passif, un utilisateur peut observer l'absence d'installation de la route du proxy par défaut dans le dispositif Edge actif et l'échec du trafic utilisant ce lien.

    Lorsqu'une paire de dispositifs Edge à HA améliorée s'affiche, le lien PPPoE se synchronise avec le dispositif Edge passif et fournit une route par défaut avec une valeur next-hop de 0.0.0.0. Par conséquent, cette route n'est pas installée sur le dispositif actif et le trafic utilisant ce lien est abandonné.

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

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

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

    Ce problème ne peut être effacé qu'en effectuant un redémarrage du service du dispositif Edge.

  • Problème résolu 87205 : Pour un client déployant un dispositif VMware SD-WAN Edge avec une passerelle partenaire, le trafic client peut être interrompu lorsqu'un dispositif Edge apprend de nouvelles routes à partir de la passerelle partenaire.

    Ce problème est dû au trafic correspondant à la Business Policy incorrecte. Par exemple, le trafic DHCP destiné à la passerelle partenaire peut plutôt être mis en correspondance avec la règle de backhaul Internet avec une interruption résultante du trafic client.

    Sans le correctif, corrigez le problème en vidant les flux d'Edge à l'aide de Diagnostic à distance (Remote Diagnostic) > Vider les flux (Flush Flows). Cette correction n'empêche pas les occurrences potentielles futures lorsque de nouvelles routes sont apprises à la passerelle partenaire par le dispositif Edge.

  • Problème résolu 87552 : Lorsqu'un dispositif VMware SD-WAN Edge est configuré pour utiliser une destination non-SD-WAN (NSD) via un dispositif Edge ou un service de sécurité cloud (CSS), le dispositif VMware SD-WAN Edge peut subir périodiquement une panne du service de plan de données et redémarrer lorsque des tunnels NSD ou CSS sont instables.

    Lorsque le dispositif Edge démonte un tunnel vers une NSD ou un CSS (IPsec ou GRE), la mise en production incorrecte d'un tunnel précédemment choisi déclenche une exception dans le service de plan de données Edge et un redémarrage du service Edge pour restaurer le service. Le redémarrage du service Edge entraîne une interruption de 10 à 15 secondes du trafic client.

    Sur un dispositif Edge sans correctif pour ce problème, l'association d'une NSD via le dispositif Edge ou le CSS à un lien WAN diminue le risque d'apparition de ce problème. En d'autres termes, au lieu de configurer une NSD ou un CSS sur plusieurs liens WAN, choisissez un seul lien WAN. Cela entraîne une perte de redondance, mais limite l'incidence de ce problème.

  • Problème résolu 88055 : Sur les modèles VMware SD-WAN Edge 3x00, un client peut observer que lorsque le débit est soutenu à 10 Gbits/s ou plus, la latence du chemin d'accès WAN peut se bloquer et dégrader la stabilité et le débit du dispositif Edge.

    Dans les environnements 10G avec une dérive d'horloge rapide entre des points de terminaison VCMP, les mesures de latence du chemin WAN peuvent se bloquer, ce qui affecte l'efficacité de l'optimisation dynamique des chemins multiples (DMPO) et entraîne une sélection incorrecte des chemins et une dégradation du débit.

  • Problème résolu 88152 : Les demandes SNMP envoyées à la sous-interface d'un dispositif VMware SD-WAN Edge ne fonctionnent pas.

    Il s'agit d'un comportement du jour 1 et toutes les demandes SNMP envoyées à une sous-interface du dispositif Edge expireront. Le correctif de ce problème ajoute la prise en charge de ces demandes SNMP à la sous-interface d'un dispositif Edge.

  • Problème résolu 88317 : Sur un dispositif VMware SD-WAN Edge qui utilise des liens publics et privés et qui dispose d'une fonctionnalité SD-WAN accessible (SD-WAN Reachable) configurée, le trafic direct n'utilise pas le lien privé comme prévu lorsqu'un lien public tombe en panne.

    Lorsqu'une Business Policy est définie pour préférer le lien public, le flux n'utilise pas le lien privé accessible SD-WAN alors que le lien public préféré est inactif. Le correctif ajoute la logique pour autoriser les liens SD-WAN accessibles lorsque la sélection de liens directs tente de découvrir des liens privés en dernier recours.

  • Problème résolu 88550 : Pour les clients qui utilisent Edge Network Intelligence, un dispositif VMware SD-WAN Edge ne peut pas communiquer avec le service Edge Network Intelligence lorsqu'un DNS n'est pas explicitement configuré.

    En cas de configuration non explicite du DNS, le service Edge Network Intelligence utilise le DNS Google par défaut. Si le DNS choisit une interface Loopback comme interface source, l'accessibilité au service est interrompue en raison de l'échec de la recherche DNS.

    Pour une entreprise cliente n'utilisant aucune build Edge avec le correctif, la solution consiste à configurer le DNS explicitement sur Orchestrator et à choisir une interface réelle comme interface source par rapport à une interface Loopback virtuelle.

  • Problème résolu 89364 : Pour un site utilisant une topologie à haute disponibilité améliorée, si un utilisateur exécute Diagnostics à distance (Remote Diagnostics) > État de l'interface (Interface Status), la vitesse de lien de l'interface du dispositif Edge passif indique 0 Mbit/s/semi-duplex.

    Les détails de la vitesse et de la négociation automatique ne sont pas extraits du dispositif Edge passif sur lequel l'interface est active et les détails ne s'affichent pas correctement.

  • Problème résolu 89596 : Un dispositif VMware SD-WAN Edge peut subir une panne du service de plan de données et redémarrer en conséquence, ce qui interrompt le trafic client.

    Ce problème peut se produire lorsqu'un client a configuré la NAT. Lorsqu'un nouveau flux utilisant la NAT est établi, il existe une condition de concurrence très rare qui peut déclencher une exception dans le service Edge qui entraîne un échec et un redémarrage.

    Sans correctif pour ce problème, la seule façon d'éviter ce problème consiste à désactiver la NAT.

  • Problème résolu 89725 : Pour les dispositifs VMware SD-WAN Edge utilisant des versions logicielles d'Edge antérieures à 5.1.0, les utilitaires de diagnostic à distance Test de bande passante du lien WAN et Traceroute peuvent ne pas fonctionner.

    Les utilitaires Test de bande passante du lien WAN et Traceroute nécessitent une entrée supplémentaire pour l'interface (pour le test de bande passante) ou l'adresse IP (pour Traceroute). Lorsqu'il rencontre ce problème, l'utilisateur ne peut pas configurer ces entrées, car l'option du menu déroulant ne s'affiche pas. Le test dans les deux cas entraîne alors une erreur.

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

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

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

  • Problème résolu 90098 : Pour une entreprise cliente sur laquelle un VPN site distant vers site distant est configuré, dans certains scénarios, un tunnel peut être tenté continuellement, même s'il ne peut pas apparaître en raison d'une modification de configuration.

    Le scénario implique qu'un dispositif Edge tente de créer un tunnel avec un dispositif Edge homologue hors ligne ou dont l'adresse IP a été modifiée. Le dispositif Edge ne se rend pas compte que l'homologue est inaccessible et tente sans cesse de créer un tunnel vers la destination inexistante qui altère les performances globales et ne peut pas être arrêté par le client.

    Ce problème est dû à l'absence de délai d'expiration pour les tunnels site distant vers site distant qui ne fonctionnent pas. En outre, le problème est difficile à résoudre, car aucun message n'est généré à l'endroit où le dispositif Edge obtient la réponse au message site distant vers site distant et aucune commande de débogage sur la passerelle connectée ne permet d'afficher les informations valides de site distant vers site distant pour un homologue.

  • Problème résolu 90216 : Traceroute peut ne pas afficher l'adresse IP correcte d'un dispositif VMware SD-WAN Hub Edge lorsque le flux de trafic provient de Client > Dispositif Spoke Edge (Spoke Edge) > Hub > Serveur (Server).

    Si une Business Policy est configurée sur un dispositif Spoke Edge pour le backhaul de son trafic vers un dispositif Hub Edge avec l'option Groupe de transport (Transport Group) configurée pour utiliser Lien filaire privé (Private Wired) et Obligatoire (Mandatory), lorsque le paquet traceroute atteint le dispositif Hub Edge, celui-ci répond avec l'adresse IP incorrecte (dans ce cas, l'adresse IP publique, au lieu de l'adresse IP privée) à traceroute.

  • Problème résolu 90884 : pour une entreprise cliente utilisant une topologie de cluster Hub/Spoke, lorsqu'un dispositif Hub Edge du cluster est réattribué à un ou plusieurs dispositifs Spoke Edge, les utilisateurs sur ces emplacements peuvent rencontrer une panne de trafic.

    Les dispositifs Hub Edge d'un cluster peuvent être réattribués dans le cadre d'un rééquilibrage du cluster lorsqu'une entreprise met à niveau le logiciel du dispositif Edge. Ce problème peut donc être observé après la mise à niveau. Lorsque ce problème se produit, la passerelle VMware SD-WAN Gateway n'envoie pas les nouvelles routes Spoke Edge au dispositif Hub Edge, car la passerelle s'attend à ce que tous les dispositifs Hub Edge disposent de toutes les routes du dispositif Spoke Edge, et ces routes ne se trouvent donc pas dans la table de routage du dispositif Hub Edge. Par conséquent, le trafic entre les dispositifs Spoke Edge et le dispositif Hub Edge dans le cluster est affecté, car le chemin de transfert est inactif.

    si le problème se produit dans une entreprise qui n'utilise pas de passerelles avec un correctif pour ce problème, vous pouvez le résoudre temporairement en exécutant la commande route reinit sur le dispositif Hub Edge. Toutefois, ce problème peut se reproduire lors d'une nouvelle réattribution du dispositif Hub Edge.

  • Problème résolu 91164 : Sur une entreprise cliente déployée avec une topologie Hub/Spoke dans laquelle le dispositif VMware SD-WAN Hub Edge est configuré pour la haute disponibilité, le dispositif HA Hub Edge peut ne pas transférer le trafic de backhaul Internet après un basculement HA.

    Ce problème est limité à un scénario dans lequel 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 de superposition non-WAN. Lorsque le dispositif Edge en veille devient actif dans un basculement HA, ces facteurs entraînent l'échec du trafic de backhaul Internet.

  • Problème résolu 91188 : Un test ping IPv6 vers un hôte connecté à un VLAN sur une interface commutée échoue si elle est effectuée lors de l'utilisation de Diagnostics à distance (Remote Diagnostics) > Test ping (Ping) et de la sélection de l'interface VLAN comme interface source.

    Le nom de l'interface source « VLAN-x » est connu uniquement pour VMware SD-WAN Edge, et le système d'exploitation Edge a besoin de l'interface source au format « br-networkx », car l'interface VLAN est créée avec ce nom dans le système d'exploitation du dispositif Edge.

  • Problème résolu 91203 : Pour une entreprise cliente configurée avec une topologie Hub/Spoke dans laquelle le dispositif VMware SD-WAN Spoke Edge est configuré pour un backhaul du trafic via un dispositif Hub Edge, un utilisateur peut observer des performances de trafic médiocres pour les flux soumis à un backhaul.

    Le tronçon de backhaul sur le dispositif Edge du Hub est déterminé par les types de route source et de destination (en d'autres termes, Source = entreprise, Destination = cloud). Toutefois, cette approche peut entraîner un comportement incohérent, car elle dépend des incidents basés sur les modifications des routes et peut entraîner des paquets abandonnés pour les flux soumis à un backhaul. Le correctif de ce problème consiste à déterminer le segment de backhaul en fonction de la messagerie du dispositif Spoke Edge.

  • Problème résolu 92454 : L'option Diagnostic à distance (Remote Diagnostic) > Traceroute ne fonctionne pas lorsque vous entrez un nom de domaine uniquement résolu en adresse IPv4 dans le champ Destination.

    Si un nom de domaine est résolu en adresse IPv4 uniquement, la commande Traceroute exécutée via Diagnostics à distance (Remote Diagnostics) ne fonctionne pas. Cela est dû au fait que le dispositif VMware SD-WAN Edge tente toujours de résoudre le nom de domaine pour l'enregistrement IPv6 et ne parvient pas à trouver l'adresse IPv4.

    Sur un dispositif Edge sans ce correctif, la solution consiste à utiliser l'adresse IPv4 correspondant au nom de domaine directement dans la commande Traceroute. L'adresse IPv4 peut être obtenue en fournissant le nom de domaine à Diagnostic à distance (Remote Diagnostic) > Test DNS (DNS Test).

  • Problème résolu 92758 : Un site avec une topologie à haute disponibilité peut rencontrer plusieurs problèmes différents sur les dispositifs VMware SD-WAN HA Edge, y compris dans un état de voyant incorrect ou une panne HA.

    L'état incorrect du voyant sur le dispositif Edge actif s'affiche en jaune au lieu de vert, même si le dispositif Edge est actif et que les liaisons WAN sont actives et stables.

    Ce problème est lié à une corruption de mémoire partagée sur le dispositif Edge qui se manifeste sous plusieurs formes. Cela peut être confirmé en extrayant les compteurs avec l'outil getcntr pour un domaine spécifique tel que vcedge.com. La sortie de l'outil indique « Le domaine n'existe pas », et le nom du compteur est introuvable.

    VMware SD-WAN repose sur l'appel système dynamique pour dériver des clés de mémoire partagée SYSV. ftok() utilise les 16 derniers bits d'inode pour calculer la clé. Cela peut entraîner une collision de clé lorsque les nombres d'inodes diffèrent d'au moins 64 000. Lorsqu'une telle collision se produit, les compteurs de mémoire partagée de tunnel dynamique peuvent corrompre les variables de mémoire partagée globales, ce qui entraîne plusieurs problèmes de dispositif Edge possibles, notamment un état de voyant incorrect, l'incapacité des compteurs ou une panne HA.

  • Problème résolu 93062 : Lorsqu'un utilisateur exécute l'état de l'interface (Interface Status) du diagnostic à distance (Remote Diagnostic) sur le VMware Orchestrator, Orchestrator renvoie une erreur pour ce test et ne se termine pas ou le test ne renvoie pas de résultats pour les interfaces acheminées.

    Le message d'erreur affiché est « erreur lors de la lecture des données pour le test ». Si le test se termine, les résultats des interfaces acheminées sont vides sans informations sur la vitesse ou le duplex. Dans tous les cas, l'état de l'interface est rompu. Ce problème est lié à la commande de débogage qui sous-tend l'état de l'interface omettant les ports DPKD activés.

    Sur un dispositif Edge sans ce correctif, l'utilisateur doit générer un bundle de diagnostics pour le dispositif Edge afin d'afficher l'état de l'interface routée

  • Problème résolu 93853 : Une passerelle VMware SD-WAN Gateway surchargée peut subir une panne du service de plan de données avec un code SIGXCPU et redémarrer le service pour reprendre.

    En cas de surcharge, plusieurs threads de passerelle effectuant diverses activités, telles que le routage et la journalisation, sont privés de ressources de CPU et ne peuvent pas terminer la tâche dans la période stipulée. Le service de passerelle interprète ces threads en retard comme étant bloqués et déclenche le signal SIGXCPU avec une fin de processus de plan de données de passerelle ultérieure.

  • Problème résolu 94204 : Un utilisateur peut observer l'échec des tentatives de génération d'un bundle de diagnostics pour un dispositif VMware SD-WAN Edge compatible VNF.

    Un bundle de diagnostics ne parvient pas à s'exécuter sur un dispositif Edge compatible VNF, car l'espace disque du dispositif Edge est insuffisant. Cela peut se produire si le dispositif Edge a généré un ou plusieurs noyaux et est causé par l'envoi de ces noyaux au dossier /vnf/tmp par le dispositif Edge. Chaque noyau est décompressé dans le dossier /vnf/tmp et, en raison de la taille décompressée d'un noyau, il remplit rapidement ce dossier, ce qui entraîne l'échec du bundle de diagnostics. 

    Les dispositifs Edge compatibles avec la fonction de réseau virtuel (VNF, Virtual Network Function) incluent les modèles suivants : 520v, 620, 640, 680 et 840.

  • Problème résolu 94401 : Sur un dispositif VMware SD-WAN Edge sur lequel le pare-feu avec état est activé, un flux TCP établi peut expirer trop rapidement et être vidé.

    Le flux TCP établi est traité comme un flux TCP non établi et est soumis à un délai d'expiration plus court. Lorsqu'une réinitialisation TCP (RST) se produit dans un flux TCP, suivie de l'établissement d'une liaison TCP à 3 voies, même si l'état TCP indique Établi (Established), le flux est vidé après avoir été soumis à un délai d'expiration du flux TCP non établi.

  • Problème résolu 94612 : Le trafic vers le préfixe du réseau BGP peut ne pas être accessible.

    Lorsque ce problème se produit, le préfixe réseau BGP n'est pas configuré sous BGP et n'est pas annoncé aux nœuds peer.

    Sur un dispositif Edge sans correctif pour ce problème, la seule solution consiste à supprimer les réseaux BGP et à les reconfigurer.

  • Problème résolu 94775 : Sur une entreprise cliente utilisant une topologie Hub/Spoke dans laquelle un dispositif VMware SD-WAN Spoke Edge effectue un backhaul de son trafic via un dispositif Hub Edge, les utilisateurs clients peuvent observer des problèmes de performances du trafic.

    Cela est dû au fait que l'indicateur incorrect est défini pour le trafic de backhaul. Les paquets soumis au backhaul sont gérés sur le dispositif Spoke Edge comme s'ils se trouvaient sur un dispositif Hub Edge. Cela entraîne des problèmes de recherche de routes sur le Hub et les paquets soumis au backhaul sont abandonnés.

  • Problème résolu 94980 : Pour un site déployé avec une topologie à haute disponibilité, le dispositif VMware SD-WAN Standby Edge passif peut rencontrer une erreur de service de plan de données et redémarrer lors de la configuration d'un lien WAN PPPoE pour les dispositifs Edge HA.

    Lors de l'examen du noyau généré par le dispositif Edge passif, le message vc_is_use_cloud_gateway_set s'affiche lors de la configuration d'un lien PPPoE.

    Sur un site HA sans correctif pour ce problème, le client doit s'assurer qu'un lien PPPoE a été configuré uniquement dans une fenêtre de maintenance pour gérer le risque de ce problème.

  • Problème résolu 95047 : Lorsqu'un utilitaire d'analyse de port de sécurité analyse un dispositif VMware SD-WAN Edge sur lequel Edge Network Intelligence (analyse) n'est pas activé, l'analyse signale la fermeture du port 514 de Syslog, ce qui signifie qu'il peut être accessible.

    Edge Network Intelligence écoute sur le port 514 (Syslog). Si les analyses (Analytics) ne sont pas activées, le port 514 reste accessible, mais il ne répond pas aux demandes. Par conséquent, un scanner de port signale que le port est « fermé » (en d'autres termes, le port est accessible, mais aucune application ne l'écoute).

  • Problème résolu 95121 : Lorsqu'une « carte SIM verrouillée » (verrouillage par mot de passe) est utilisée dans un modèle de dispositif VMware SD-WAN Edge 510-LTE ou 610-LTE, le client ne parvient pas à établir une connexion sur le réseau.

    Les utilisateurs rencontrent des problèmes d'établissement de chemins lors de l'utilisation de cartes SIM LTE verrouillées avec les emplacements SIM des modèles Edge 510-LTE et 610-LTE, car le déverrouillage de la carte SIM ne fonctionne pas à partir d'Orchestrator. Cela est dû à un manque de prise en charge des cartes SIM verrouillées dans les scripts ModemManager du dispositif Edge.

  • Problème résolu 95501 : Pour une entreprise cliente qui utilise une topologie Hub/Spoke et BGP pour le routage, les utilisateurs clients sur les dispositifs VMware SD-WAN Spoke Edge peuvent observer des performances médiocres du trafic.

    Un administrateur constate que le dispositif Spoke Edge préfère les routes marquées avec un ensemble de liens montants à partir d'un Hub non inclus dans son profil sur le dispositif Hub Edge configuré pour être utilisé pour ce dispositif Spoke Edge. Cela est dû au fait que le trafic du dispositif Spoke Edge prend un chemin dynamique site distant vers site distant pour les préfixes de lien montant.

    Ce problème est dû à la réinitialisation par SD-WAN de l'indicateur de lien montant pour le routage des messages reçus d'un dispositif Hub Edge. Par conséquent, lorsqu'un tunnel dynamique site distant vers site distant est formé, des routes directes sont installées pour ces préfixes de lien montant, ce qui entraîne un routage inefficace et une dégradation des performances du trafic.

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

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

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

  • Problème résolu 96626 : Lorsqu'une adresse IP secondaire est attribuée à une interface VMware SD-WAN Edge, les connexions via l'adresse IP secondaire échouent.

    Toute demande provenant d'un autre site distant vers une adresse IP dans le réseau secondaire génère un ARP à partir de l'adresse IP principale plutôt que de l'adresse IP secondaire. Par conséquent, le protocole ARP reste non résolu, ce qui entraîne une panne du trafic passant par l'adresse IP secondaire.

  • Problème résolu 96739 : Lorsqu'un utilisateur examine l'onglet Surveiller (Monitor) > Application pour un dispositif VMware SD-WAN Edge sur un dispositif VMware SASE Orchestrator, l'écran peut afficher les noms de domaine complets de destination avec les noms de domaine incorrects.

    Ce problème peut se produire lorsque les statistiques du dispositif Edge atteignent sa limite (appelée condition de dépassement). Au lieu d'afficher Dépassement (Overflow) pour ces statistiques, Orchestrator affiche des noms de domaine aléatoires sur le nom de domaine complet de destination de l'onglet Application.

  • Problème résolu 96994 : Lors d'une collecte SNMP sur un dispositif VMware SD-WAN Edge, certaines interfaces peuvent ne pas s'afficher.

    Les interfaces manquantes peuvent être des interfaces valides qui étaient censées être visibles sur snmpwalk. Toutefois, en raison de l'apparence d'une interface non valide dans la liste de matériels du dispositif Edge, les interfaces valides qui s'affichent après celle non valide de la liste ne seront ni visibles ni renvoyées par snmpwalk. Une interface ici n'est pas valide si elle figure dans la liste de matériels, mais ne s'affiche pas lors de l'exécution de la commande ifconfig sur le dispositif Edge.

    Bien que ce problème puisse potentiellement affecter n'importe quel dispositif Edge, il est plus susceptible de survenir sur un dispositif Edge virtuel déployé à l'aide d'Azure. Cela est dû au fait que le dispositif Edge Azure a tendance à répertorier un plus grand nombre d'interfaces sur sa liste de matériels que le nombre d'interfaces identifiées dans le dispositif Edge proprement dit à l'aide de ifconfig.

  • Problème résolu 97152 : Lorsqu'une qu'une Business Policy est configurée pour une entreprise cliente avec un groupe de services comme n'importe quel élément filaire et le mode de lien « Disponible » (Available), le trafic n'est pas dirigé vers un lien sans fil lorsque le ou les liens filaires tombent en panne et que les utilisateurs clients sur le site constatent la panne de leur trafic qui correspond à cette règle.

    Lorsqu'une règle de Business Policy dispose d'un groupe de services explicite de liens WAN filaires avec un mode de lien Disponible (Available) et que des liens sans fil sont disponibles sur le site, le trafic utilisant cette règle devrait basculer vers le ou les liens WAN filaires si ceux se trouvant dans le groupe de services tombent en panne (en d'autres termes, deviennent indisponibles) pour garantir le flux transparent du trafic correspondant à cette règle. Pour ce problème, la direction du trafic vers les liens sans fil ne se produit pas.

  • Problème résolu 97321 : à partir du moment où un utilisateur active l'analyse Edge Network Intelligence sur un dispositif VMware SD-WAN Edge, celui-ci peut potentiellement déclencher un redémarrage du service Edge, chaque instance entraînant entre 10 et 15 secondes d'interruption du trafic client.

    Lorsque l'analyse est activée sur le dispositif Edge, celui-ci peut subir une condition de mémoire insuffisante suivie d'un état de mémoire « à double libération ». Le dispositif Edge redémarre son service pour restaurer la mémoire.

    Les symptômes de ce problème peuvent se produire plusieurs fois lorsque les analyses sont activées.

  • Problème résolu 99718 : BGP Neighbor n'est pas établi lorsque l'adresse IP secondaire sur une interface virtuelle du commutateur (SVI, Switch Virtual Interface) est utilisée.

    Lorsque le dispositif Edge traite les paquets d'entrée, il vérifie si l'adresse de destination du paquet d'entrée correspond à l'adresse IP de l'interface d'entrée. Étant donné que seules les adresses IP principales sont comparées, les paquets ayant une adresse IP de destination comme adresse IP secondaire sont abandonnés. Par conséquent, la session BGP ne se forme pas sur cette adresse IP secondaire.

  • Problème résolu 100363 : Une passerelle VMware SD-WAN Gateway peut subir une panne du service de plan de données et déclencher un redémarrage du service, ce qui entraîne une interruption du trafic de 1 à 5 secondes.

    Ce problème se produisait lors du test de contrainte avec l'échec survenant à futex_abstimed_wait et le résultat d'un thread bloqué qui déclenche l'échec du service et le redémarrage.

Problèmes d'Orchestrator résolus

Résolus dans la version R51010-20231215-GA d'Orchestrator

La build R51010-20231215-GA d'Orchestrator a été publiée le 18/12/2023 et constitue la 10e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout le problème important ci-dessous depuis la 9e build cumulative R5109-20231003-GA d'Orchestrator.

  • Problème résolu 117941 : la case Annonce VLAN (VLAN Advertise) s'affiche toujours comme non cochée dans l'interface utilisateur d'Orchestrator.

    Même lorsqu'un utilisateur coche les cases Annonce VLAN (VLAN Advertise) et Enregistrer les modifications (Save Changes), la case Annonce VLAN (VLAN Advertise) de l'interface utilisateur d'Orchestrator n'est plus sélectionnée.

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

    Pour éviter ce problème sur une instance d'Orchestrator 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 résolu 128310 : Les utilisateurs de VMware SASE Orchestrator peuvent rencontrer des ralentissements globaux et des échecs d'API en raison de problèmes avec le service de base de données d'Orchestrator. Les autres effets secondaires incluent les passerelles/dispositifs Edge SD-WAN apparaissant hors ligne dans l'interface utilisateur, les modifications de configuration apportées via l'interface utilisateur d'Orchestrator non transférées aux dispositifs Edge SD-WAN cibles et une perte de capacités de génération de rapports.

    Ces problèmes sont tous dus à l'échec du service de base de données d'Orchestrator avec l'erreur : trop de fichiers ouverts (too many open files). Cette erreur peut être observée par un utilisateur opérateur sur le dispositif VMware SASE Orchestrator via les journaux. Un utilisateur d'entreprise ou partenaire accédant à VMware SASE Orchestrator via l'interface utilisateur rencontre des ralentissements et des échecs intermittents de l'API, ce qui génère des messages d'erreur sur l'interface utilisateur.

  • Problème résolu 129239 : sur la page Configurer (Configure) > Profil (Profile) de l'interface utilisateur d'Orchestrator, lorsqu'un utilisateur modifie un paramètre au niveau du profil et tente de l'enregistrer, il peut observer que l'appel d'API arrive à expiration et échoue.

    Lorsque ce problème se produit, l'interface utilisateur d'Orchestrator affiche une bannière d'erreur rouge sur la page du navigateur qui indique « expiration de configuration/updateConfigurationModule (configuration/updateConfigurationModule time out) ». Ce problème est dû au fait que d'autres requêtes de base de données Orchestrator prennent trop de temps à s'exécuter, ce qui entraîne l'expiration de la tentative d'enregistrement des nouveaux paramètres du profil.

  • Problème résolu 131789 : Lors de la configuration de Single Sign-On (SSO) pour une organisation, les utilisateurs ne peuvent pas se connecter à Orchestrator, même si les informations de rôle sont présentes dans la réponse du fournisseur d'identité (IdP).

    Orchestrator ne peut pas correspondre au rôle d'un utilisateur se connectant via Single Sign-On (SSO), si le fournisseur d'identité envoie des informations de rôle dans une structure JSON imbriquée. À partir de la version 5.0.1.7, Orchestrator peut référencer et faire correspondre le rôle d'un utilisateur SSO, même s'il est présent dans une structure JSON imbriquée. Si ce problème se produit sur un dispositif Orchestrator sans correctif pour ce problème, la solution consiste à configurer le fournisseur d'identité afin d'envoyer le détail du rôle au niveau immédiat, et non dans la structure imbriquée.

Résolu dans Orchestrator version R5109-20231003-GA

La build R5109-20231003-GA d'Orchestrator a été publiée le 5/10/2023 et constitue la 9e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout le problème important ci-dessous depuis la 8e build cumulative R5108-20230916-GA d'Orchestrator.

  • Problème résolu 119938 : Pour un client qui utilise l'automatisation pour les tunnels Zscalar, la création d'un tunnel IPsec automatisé à partir d'un dispositif VMware SD-WAN Edge vers Zscaler peut prendre beaucoup de temps.

    Lorsque les clients configurent des sous-emplacements Zscaler dans Edge > Paramètres du périphérique (Device Settings), la synchronisation de ces configurations avec le cloud Zscaler peut prendre beaucoup de temps. Cela est dû au fait que le cloud Zscaler doit mettre à jour ses enregistrements pour chaque sous-emplacement, ce qui peut être un processus long.

    Ce problème est dû à l'infrastructure d'automatisation sur Orchestrator, qui met en file d'attente la création de tunnel IPsec et les actions de création de sous-emplacements dans la file d'attente d'automatisation. Elle met également en file d'attente les actions de mise à jour dans la file d'attente d'automatisation lorsque l'adresse IP WAN du dispositif Edge change. Toutefois, le temps d'attente des éléments dans la file d'attente augmente en raison du grand nombre d'actions de mise à jour. Dans certains environnements de déploiement de clients, l'adresse IP WAN du dispositif Edge peut changer jusqu'à 4 000 fois en une journée (par exemple, les liens WAN mobiles).

  • Problème résolu 128310 : Les utilisateurs de VMware SASE Orchestrator peuvent rencontrer des ralentissements globaux et des échecs d'API en raison de problèmes avec le service de base de données d'Orchestrator. Les autres effets secondaires incluent les passerelles/dispositifs Edge SD-WAN qui s'affichent hors ligne dans l'interface utilisateur, les modifications de configuration apportées via l'interface utilisateur d'Orchestrator non transférées vers les dispositifs SD-WAN Edge cibles et une perte de capacités de génération de rapports.

    Ces problèmes sont tous dus à l'échec du service de base de données d'Orchestrator avec l'erreur : trop de fichiers ouverts. Cette erreur peut être constatée par un utilisateur opérateur sur VMware SASE Orchestrator via les journaux. Un utilisateur d'entreprise ou partenaire accédant à VMware SASE Orchestrator via l'interface utilisateur subit une lenteur et des échecs intermittents de l'API, ce qui entraîne des messages d'erreur sur l'interface utilisateur.

Résolu dans Orchestrator version R5108-20230916-GA

La build R5108-20230916-GA d'Orchestrator a été publiée le 20/09/2023 et constitue la 8e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout le problème important ci-dessous depuis la 7e build cumulative R5107-20230722-GA d'Orchestrator.

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

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

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

    L'état devrait indiquer En veille Inactif (Standby Idle) avec un point d'état gris, mais ni le type de lien ni l'état de la sauvegarde ne sont affichés. Il s'agit d'un défaut superficiel, car le lien WAN joue son rôle de sauvegarde.

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

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

  • Problème résolu 106191 : Un utilisateur ne peut pas apporter de modifications à une configuration VMware SD-WAN Edge si le dispositif Edge utilise un profil dans lequel une interface est configurée avec une adresse IP statique.

    Si une tentative de modification de la configuration du dispositif Edge est effectuée, l'interface utilisateur de VMware SASE Orchestrator affiche le message d'erreur suivant : « invalid probe interval for interface » et empêche l'enregistrement des modifications.

    Sur un dispositif Orchestrator sans correctif pour ce problème, la seule solution consiste à créer un profil sans attributions d'interface statique et à l'appliquer au dispositif Edge.

  • Problème résolu 115981 : Pour une entreprise cliente utilisant l'APIv2 de VMware SASE Orchestrator, lors de l'exécution de l'API pour obtenir des événements d'entreprise, Orchestrator renvoie uniquement un ensemble limité.

    L'appel spécifique est https://\{api_host}//api/sdwan/v2/enterprises/{enterpriseLogicalId}/events. Lorsqu'il est appelé, il renvoie uniquement la hiérarchie de niveau supérieur et inclut des détails tels que enterpriseName, EdgeName, segmentName ou edgeID. En outre, APIv2 ne prend pas en charge le parcours de graphe.

    Sur un dispositif Orchestrator sans correctif pour ce problème, la seule solution consiste à utiliser APIv1, ce qui force un client à gérer deux ensembles de familles d'API. En outre, APIv1 ne prend pas en charge Cloud Web Security.

  • Problème résolu 116531 : Si un utilisateur tente de générer un rapport sur VMware SASE Orchestrator dans lequel au moins une description du dispositif Edge inclut une virgule (,), le format du rapport peut ne pas être correct.

    Lorsqu'une description du dispositif Edge inclut une virgule (comme indiqué dans la capture d'écran ci-dessous), le service de rapport d'Orchestrator confond cela et coupe le texte après chaque virgule dans la colonne suivante du rapport, au lieu de garder la chaîne de texte entière dans la colonne Description du dispositif Edge comme attendu.

    Par conséquent, au lieu que la colonne Octets transmis ait les valeurs qui lui sont associées, elle affiche le texte situé après la première virgule, alors que le texte après la deuxième virgule (le cas échéant) correspondrait à Octets reçus, etc. Le rapport inclut toujours les données pour les octets transmis et les octets reçus, il est simplement décalé vers la droite et n'est pas aligné sur les colonnes correctes.

    Sur un dispositif Orchestrator sans correctif pour ce problème, l'utilisateur doit s'assurer que la description du dispositif Edge n'utiliser pas de virgules.

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

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

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

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

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

  • Problème résolu 121085 : Si un administrateur partenaire se trouve sur la page Paramètres globaux (Global Settings) > Gestion des utilisateurs (User Management) > Autorisations de service (Service Permissions), l'option « Rétablir les valeurs système par défaut » (Reset to System Default) ne fonctionne pas comme prévu.

    Le comportement attendu lorsque Rétablir les valeurs système par défaut (Reset to System Default) est sélectionné est que tous les modules d'autorisation de rôle personnalisé reviennent à un état Non publié (Unpublished) lorsque les paramètres par défaut des autorisations de rôle d'utilisateur sont restaurés. Toutefois, l'utilisateur partenaire constate qu'un ou plusieurs modules personnalisés restent dans un état Publié (Published) et que ceux qui restent publiés (Published) ne peuvent pas être modifiés ou supprimés.

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

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

    Ce problème se produit uniquement sur la nouvelle interface utilisateur. Si ce problème se produit sur un dispositif Orchestrator 5.1.x sans correctif pour ce problème, basculez vers l'interface utilisateur classique pour configurer la VNF.

  • Problème résolu 121469 : lorsqu'un utilisateur accède à la page Paramètres globaux (Global Settings) > Gestion des utilisateurs (User Management), une bannière sur l'interface utilisateur indique que tous les comptes d'utilisateur sont verrouillés, alors que la plupart des comptes, voire la totalité d'entre eux, ne sont pas réellement verrouillés.

    La bannière de message d'erreur d'un compte d'utilisateur indique « Ce compte a été verrouillé en raison d'un trop grand nombre de tentatives de connexion infructueuses (This account has been locked due to too many failed login attempts) », même si, lorsque vous consultez la page de la liste d'utilisateurs, leur état indique Déverrouillé (Unlocked) et que la connexion à l'interface utilisateur locale reste possible.

  • Problème résolu 124778 : Lors de l'utilisation de la nouvelle interface utilisateur sur VMware SASE Orchestrator, si un client accède à Paramètres globaux (Global Settings) > Configuration du client (Customer Configuration), il ne voit pas l'option permettant de configurer sa stratégie de sécurité.

    La section Stratégie de sécurité permet à un client de configurer sa Proposition d'IPsec Edge, notamment le chiffrement, le groupe DH, etc. Cette option est présente sur l'interface utilisateur classique, mais est absente dans la nouvelle interface utilisateur.

Résolu dans Orchestrator version R5107-20230722-GA

La build R5107-20230722-GA d'Orchestrator a été publiée le 22/07/2023 et constitue la 7e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout le problème important ci-dessous depuis la 6e build cumulative R5106-20230705-GA d'Orchestrator.

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

    La nouvelle interface utilisateur calcule de manière incorrecte le masque externe NAT côté LAN à partir du préfixe d'adresse interne. Lorsque les règles ne sont pas écrites de sorte que le préfixe interne et le préfixe externe sont identiques (en d'autres termes, 1:1), le comportement des règles change et peut devenir non fonctionnel si un utilisateur modifie une règle NAT côté LAN à partir de la nouvelle interface utilisateur.

    Sur une instance d'Orchestrator sans correctif pour ce problème, le client doit uniquement utiliser l'interface utilisateur classique d'Orchestrator pour configurer des règles NAT côté LAN.

Résolu dans Orchestrator version R5106-20230705-GA

La build R5106-20230705-GA d'Orchestrator a été publiée le 06/07/2023 et constitue la 6e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout les problèmes importants ci-dessous depuis la 5e build cumulative R5105-20230611-GA d'Orchestrator.

  • Problème résolu 84772 : Lorsque le serveur DHCP IPv6 d'un VLAN est configuré comme type Relais (Relay) au niveau du profil, si un utilisateur remplace le type par Activé (Activated) au niveau du dispositif Edge à l'aide du remplacement du dispositif Edge et désactive par la suite le remplacement du dispositif Edge, le dispositif Edge continue d'utiliser le type Activé (Activated) plutôt que de revenir au type Relais (Relay) fourni par le profil.

    VMware SASE Orchestrator ne parvient pas à imposer la configuration du profil une fois le remplacement du dispositif Edge désactivé, ce qui entraîne des paramètres de serveur IPv6 incorrects au niveau du dispositif Edge affecté.

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

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

  • Problème résolu 115433 : Un utilisateur disposant du rôle « Support de l'entreprise » (Enterprise Support) ne peut pas voir les détails de la configuration DHCP lorsqu'il examine la nouvelle interface utilisateur de VMware SASE Orchestrator.

    Le même utilisateur Support de l'entreprise (Enterprise Support) peut voir les détails de configuration DHCP s'il utilise l'interface utilisateur classique.

  • Problème résolu 116633 : Lors de la connexion à VMware SASE Orchestrator à l'aide de Safari ou de Firefox, si un utilisateur configure un VLAN non valide au niveau du profil (par exemple, ""), puis configure une valeur VLAN valide au niveau du dispositif VMware SD-WAN Edge, l'appel aboutit, mais affiche une erreur.

    La valeur d'interface pour laquelle aucune valeur n'est définie doit être null, mais est en fait vlanID = "". Si un utilisateur se connecte à Orchestrator avec un navigateur basé sur Chromium, ce problème n'est pas observé.

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

    Ce problème est propre à la nouvelle interface utilisateur d'Orchestrator et est dû à un problème de serveur frontal qui ne prend pas en compte les liens WAN dégradés ou inactifs. La surveillance fonctionne comme prévu dans l'interface utilisateur classique.

  • Problème résolu 117988 : L'option « Apprentissage de route entrante » (Inbound Route Learning) avec la case « Correspondance exacte » (Exact Match) configurée pour OSPF sous une interface VMware SD-WAN ne correspond pas à ce qui est configuré sur le dispositif Edge lorsque vous comparez les valeurs de l'interface utilisateur classique et celles de la nouvelle interface utilisateur de VMware SASE Orchestrator.

    Une option Correspondance exacte (Exact Match) n'affiche pas la valeur correcte, même si elle est correctement stockée dans la base de données du dispositif Edge lorsque vous examinez la nouvelle interface utilisateur. Les valeurs correctes sont représentées dans l'interface utilisateur classique.

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

    L'utilisateur observe l'erreur suivante : l'utilisateur ne dispose pas des privilèges requis pour accéder à [enterpriseUser/sendEnterpriseUserPasswordResetEMail] (user does not have privileges required to access [enterpriseUser/sendEnterpriseUserPasswordResetEMail]). Ce problème se produit uniquement sur la nouvelle interface utilisateur et est dû à des paramètres de demande manquants. Si ce problème se produit, l'utilisateur peut basculer vers l'interface utilisateur classique. La réinitialisation du mot de passe fonctionne alors comme prévu.

  • Problème résolu 118074 : Un utilisateur peut ne pas être en mesure d'ouvrir certains paramètres de périphérique sur la page Configurer (Configure) > Edge > Périphérique (Device) de la nouvelle interface utilisateur de VMware SASE Orchestrator.

    Les paramètres qui peuvent ne pas être accessibles incluent : Interfaces, IPv6, VPN Cloud (Cloud VPN), Destination non-SD-WAN (NSD) [Non SD-WAN Destination] et Service de sécurité cloud (CSS) [Cloud Security Service]. Le problème vient du fait que les paramètres WAN nécessitent une adresse IP publique. En l'absence de cette adresse, une erreur est générée sur la nouvelle interface utilisateur et bloque l'accès à ces paramètres. Les paramètres du périphérique fonctionnent comme prévu dans l'interface utilisateur classique.

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

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

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

    Les icônes pour lesquelles le remplacement du dispositif Edge est coché doivent être de couleur unie, mais, au lieu de cela, elles sont vides. L'interface utilisateur classique d'Orchestrator affiche correctement des icônes de couleur unie lorsqu'un remplacement du dispositif Edge est configuré pour une catégorie particulière.

  • Problème résolu 119733 : La base de données de VMware SASE Orchestrator peut subir une panne et cesser de fonctionner.

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

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

    Lorsque ce problème se produit, l'utilisateur voit une « erreur de méthode » sur la page de l'interface utilisateur lors de la création d'un rôle et les privilèges ne peuvent pas être chargés.

     

Résolu dans Orchestrator version R5105-20230611-GA

La build R5105-20230611-GA d'Orchestrator a été publiée le 13/06/2023 et constitue la 5e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout les problèmes importants ci-dessous depuis la 4e build cumulative R5104-20230426-GA d'Orchestrator.

  • Problèmes se produisant uniquement sur la nouvelle interface utilisateur d'Orchestrator et non sur l'interface utilisateur classique d'Orchestrator

    Orchestrator version 5.1.0.5 inclut un grand nombre de correctifs associés aux problèmes qu'un client peut rencontrer uniquement lors de l'utilisation de la nouvelle interface utilisateur et qui ne se produisent pas lors de l'utilisation de l'interface utilisateur classique. Le tableau ci-dessous répertorie tous ces correctifs avec une description des symptômes de chaque problème.

    Problèmes résolus de la nouvelle interface utilisateur uniquement

    Ticket

    Symptôme/Description

    Problème résolu n° 87089

    L'utilisateur n'a pas la possibilité de modifier l'adresse du client sur la page Surveiller (Monitor) > Dispositifs Edge (Edges) > Sources. Le correctif ajoute une icône de crayon bleu sur laquelle vous pouvez cliquer pour modifier une entrée.

    Problème résolu n° 112044

    Pour un site sur lequel une destination non-SD-WAN via un dispositif Edge de type Zscaler est déployée, lorsque vous regardez dans la page Surveiller (Monitor) > Services réseau (Network Services), la nouvelle interface utilisateur n'affiche pas la colonne Abonnements IaaS (IaaS Subscriptions) dans la page État du déploiement (Deployment Status).

    Problème résolu n° 112451

    Lorsqu'un utilisateur modifie un profil de configuration et que sous Périphérique (Device) > Interfaces > Vos modèles Edge (Your Edge Models) l'utilisateur sélectionne le dispositif Edge 3810, la page du navigateur Web ne répond plus et ne peut pas être enregistrée. L'utilisateur doit actualiser la page pour la récupérer. Le client ne peut pas utiliser le dispositif Edge 3810 pour ce profil.

    Problème résolu n° 112500

    Pour un site sur lequel un service de sécurité cloud (CSS, Cloud Security Service) de type Zscaler est déployé, lorsque vous regardez dans la page Surveiller (Monitor) > Dispositifs Edge (Edges) et que vous passez le curseur sur les tunnels du dispositif Edge, l'interface utilisateur n'affiche ni la ville, ni l'état du CSS Zscaler.

    Problème résolu n° 112809

    Un administrateur client disposant du rôle Entreprise en lecture seule peut afficher la page Surveillance (Monitoring) > Routage (Routing) dans l'interface utilisateur.

    Problème résolu n° 112906

    Un utilisateur peut observer que les pages de l'interface utilisateur se chargent avec un formatage inhabituel comportant de grandes sections d'espace blanc.

    Problème résolu n° 112912

    Un administrateur client ayant le rôle Support de l'entreprise (Enterprise Support) n'a pas la possibilité de sélectionner Actions à distance (Remote Actions) > Redémarrer (Reboot) pour un dispositif Edge.

    Problème résolu n° 113254

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

    Problème résolu n° 113366

    Un utilisateur ne peut pas configurer une route statique où l'adresse IP secondaire du VLAN est le next-hop.

    Problème résolu n° 113963

    Si un utilisateur crée une règle de pare-feu et définit une application pour cette règle, puis modifie ultérieurement la même règle et change l'application, la modification n'est pas appliquée et la règle conserve l'application précédente.

    Problème résolu n° 114291

    Si un service de sécurité cloud (CSS, Cloud Security Service) est configuré sur un profil, l'utilisateur ne peut pas passer d'un segment à l'autre sans avoir la possibilité de sauvegarder les Paramètres du périphérique (Device Settings) après que le CSS a été modifié sur plusieurs segments différents.

    Problème résolu n° 114564

    L'utilisateur ne peut pas configurer le Paramètre 802.1P (802.1P Setting) dans le cadre de la configuration facultative d'une interface Edge.

    Problème résolu n° 114602

    L'utilisateur n'a pas la possibilité de configurer des alertes d'opérateur ou des alertes d'entreprise sous Paramètres de service (Service Settings) > Alertes et notifications (Alerts & Notifications).

    Problème résolu n° 114912

    La page Présentation du partenaire (Partner Overview) n'inclut pas les paramètres du Contrat d'utilisateur (User Agreement).

    Problème résolu n° 115307

    Lorsqu'une session utilisateur reste inactive suffisamment longtemps pour déclencher un délai d'expiration, l'interface utilisateur n'affiche pas de message de déconnexion et passe plutôt en mode veille. Lorsque l'utilisateur accède à l'interface utilisateur, l'Orchestrator « se réveille » et lui donne accès au lieu de le rediriger vers la page de connexion.

    Problème résolu n° 115439

    Lorsqu'un utilisateur accède à Configurer (Configure) > Profil (Profile) > Paramètres du périphérique (Device Settings) > BGP, il constate que BGP est présent, mais s'il trie par Segment pris en charge (Segment Aware), l'option pour configurer BGP est manquante.

    Problème résolu n° 115653

    Lorsqu'un administrateur partenaire consulte la page Gérer les clients (Manage Customers), l'interface utilisateur n'indique pas si le client utilise des passerelles dans l'état de service Suspendu. Cela empêche le partenaire de prendre des mesures en temps opportun pour s'assurer que le client utilise uniquement des passerelles actives.

    Problème résolu n° 115719

    Une règle de Backhaul disparaît de la page Configurer (Configure) > Business Policy si une modification est apportée aux Paramètres du périphérique (Device Settings) au niveau du profil.

    Problème résolu n° 116523

    Lorsqu'un utilisateur effectue une configuration d'insertion de la VNF et tente de configurer la haute disponibilité de la VNF dans le dispositif Edge, l'Orchestrator n'enregistre pas la modification de la VNF une fois la HA configurée.

    Problème résolu n° 117527

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

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

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

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

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

  • Problème résolu 107180 : lorsqu'un utilisateur configure une VNF de type Fortinet, il ne peut pas voir la version 6.49 ou 7.2.0 de l'image Fortinet dans le menu déroulant.

    Ces images sont prises en charge dans la version 5.1.0, mais ne sont pas accessibles par un client.

  • Problème résolu 107766 : Lorsqu'un client configure une destination non-SD-WAN via un dispositif Edge ou un service de sécurité cloud (CSS), et configure également l'option Contrôle de santé de niveau 7 (L7) [Level 7 (L7) Health Check], le client peut constater que les tunnels sont marqués comme étant inactifs ou actifs de manière inattendue par rapport à ce qui devrait se produire en fonction de sa valeur de configuration de contrôle de santé L7 (L7 Health Check).

    Le problème vient du fait qu'Orchestrator transfère vers VMware SD-WAN Edge les paramètres de contrôle de santé L7 (L7 Health Check) par défaut, quel que soit la configuration effectuée par le client. Par conséquent, même si les conditions du tunnel correspondent à la configuration effectuée par le client, l'état du tunnel peut rester inchangé, car il respecte la valeur de contrôle de santé L7 (L7 Health Check).

  • Problème résolu 110826 : lorsqu'un dispositif VMware SD-WAN Edge est attribué à une entreprise cliente, le dispositif VMware SASE Orchestrator ne déplace pas automatiquement le dispositif Edge vers l'onglet « Inventaire attribué (Assigned Inventory) » de l'application de gestion de l'inventaire Maestro.

    Lorsque des dispositifs Edge non attribués sont demandés à Maestro et que l'Orchestrator recherche des numéros de série déjà attribués, le numéro de modèle d'Edge n'est pas comparé, ce qui entraîne des problèmes de double attribution des dispositifs Edge.

  • Problème résolu 111957 : Lorsqu'un opérateur met à niveau un dispositif VMware SASE Orchestrator, les utilisateurs peuvent constater des erreurs liées à l'échec des mises à jour longues de schémas. Par exemple, les routes récemment apprises (BGP ou OSPF) peuvent être manquantes sur la page OFC. Des erreurs s'observeront également dans les journaux de chargement sur un dispositif Orchestrator lié aux routes apprises.

    Une clé étrangère officielle sur VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC est abandonnée et rajoutée lors d'une mise à niveau d'Orchestrator de la version 4.2.x vers la version 4.3.x ou ultérieure comme mise à jour longue de schéma. Cette clé étrangère n'existait pas déjà sur des dispositifs Orchestrator dont le chemin de mise à niveau via certaines build 2.1.x comportait un défaut de mise à niveau et une passerelle qui apprenait les routes BGP a été supprimée d'Orchestrator. Dans ces dispositifs Orchestrator, l'ajout de la clé étrangère sur la version 4.2.x > 4.3.x+ la mise à niveau échouent si une clé étrangère enfreint les enregistrements déjà présents dans la table.

    Le correctif de ce problème permet de corriger la cause principale en supprimant la clé étrangère qui enfreint les enregistrements et en rajoutant cette dernière.

    Si vous effectuez la mise à niveau vers un dispositif Orchestrator sans correctif pour ce problème, la solution consiste à exécuter la requête suivante dans le schéma VeloCloud MySQL: DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in (select id from VELOCLOUD_GATEWAY), et ensuite, déclencher de nouveau les mises à jour de schéma de longue durée.

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

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

  • Problème résolu 112605 : un client peut observer que lorsqu'il tente d'attribuer un cluster Hub via Configurer (Configure) > Périphérique (Device) > VPN cloud (Cloud VPN) > Dispositif Edge (Edge) vers les sites SD-WAN, le profil ne répond pas et la configuration ne peut pas être enregistrée.

    L'Orchestrator crée des associations de configuration en double lorsqu'il y a plusieurs Business Policy de backhaul et les références en double déclenchent l'échec de la configuration et de l'affectation des Clusters Hub.

  • Problème résolu 112992 : lorsqu'une entreprise cliente est migrée d'un dispositif VMware SASE Orchestrator vers un autre, l'Orchestrator ajoute des enregistrements UUID.

    L'enregistrement UUID est ajouté aux enregistrements VELOCLOUD_ENTERPRISE_OBJECT alors qu'il ne devrait pas l'être.

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

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

  • Problème résolu 113375 : pour un dispositif VMware SASE Orchestrator déployé avec une topologie de récupération d'urgence (DR, Disaster Recovery), lorsqu'Orchestrator est mis à niveau de la version 4.5.x vers la version 5.1.x, la mise à niveau risque d'échouer.

    Le script de mise à niveau et les iptables échouent tous avec le code de retour 1. Ce problème peut se déclencher pendant la période où les instances d'Orchestrator active et passive exécutent différentes versions logicielles et où les iptables ne sont pas correctement chargés lorsque l'instance d'Orchestrator passive tente d'effectuer une mise à niveau (ce qui est prévu et temporaire), et l'erreur fait échouer l'ensemble de la mise à niveau. Le correctif transforme simplement l'erreur iptables en avertissement et permet à la mise à niveau de se poursuivre.

  • Problème résolu 114240 : dans le cas de la proposition d'IPsec Edge, lorsqu'un utilisateur modifie le chiffrement en AES-128-GCM ou AES-256-GCM et enregistre la configuration, l'interface utilisateur Orchestrator génère une erreur.

    L'erreur indique : « instance.ipsec.encryption is not one of enum values: AES_128_CBC, AES_256_CBC, DES_CBC ». Ce problème est dû au fait que les deux chiffrements de type GCM sont ajoutés par erreur au menu Chiffrement (Encryption) alors qu'il ne s'agit pas d'options valides. Ces options sont supprimées dans la version mise à jour de l'Orchestrator.

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

    Ce problème a été constaté sur un dispositif Orchestrator avec environ 2 000 dispositifs Edge connectés tout en utilisant également des services de sécurité cloud (CSS) et pourrait se produire avec ce nombre de dispositifs Edge connectés ou plus. Il est dû au fait que plusieurs processus Orchestrator liés aux configurations du dispositif Edge, du profil et du réseau sont chargés depuis les dispositifs Edge vers Orchestrator et prennent beaucoup plus de temps que prévu (environ 60 secondes ou plus).

  • Problème résolu 116141 : Lorsqu'un utilisateur modifie les paramètres du périphérique sur un profil de configuration, VMware SASE Orchestrator prend un temps excessif pour valider les modifications.

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

  • Problème résolu 116770 : lorsqu'un utilisateur opérateur crée une autorité de certification (CA, Certificate Authority) externe avec une longueur de chaîne de 2 ou plus en racine d'approbation, le dispositif VMware SASE Orchestrator n'autorise pas une valeur pathLengthConstraint de 0 dans un subordonné.

    Un subordonné n'étant pas autorisé à signer celui qui lui est inférieur est une configuration valide et devrait être autorisé par l'Orchestrator, mais un processus bloque l'enregistrement de la configuration.

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

    Ce problème se produit lorsqu'une entreprise cliente est supprimée d'Orchestrator et que l'entreprise supprimée était associée à un profil d'opérateur par son ID logique dans la base de données d'Orchestrator. Lorsque l'entreprise est supprimée, le profil d'opérateur est également supprimé. Les clients dont la Gestion des images Edge (Edge Image Management) est configurée et qui disposent de plusieurs profils d'opérateur et auxquels ce profil d'opérateur supprimé a été attribué par défaut, se voient alors attribuer un profil d'opérateur qui reste disponible dans leur menu Gestion des images Edge (Edge Image Management). Par conséquent, un profil d'opérateur contenant une version d'Edge beaucoup plus ancienne peut être attribué au client, et le logiciel des dispositifs Edge auxquels ce profil d'opérateur est attribué peut être modifié et éventuellement rétrogradé avec des effets potentiellement perturbateurs, notamment une panne réseau si le dispositif Edge exécute désormais une version antérieure qui ne prend pas en charge les fonctionnalités que le client utilise.

  • Problème résolu 116976 : lorsqu'un administrateur partenaire se connecte à un dispositif VMware SASE Orchestrator, il peut constater que l'Orchestrator n'affiche pas l'état réel des liens WAN qui sont inactives pendant plus de 24 heures sur les dispositifs VMware SD-WAN Edge qu'il gère.

    L'API Orchestrator renvoie uniquement des liens récents pour les partenaires/MSP, tandis que les utilisateurs standard de l'entreprise cliente obtiennent les informations d'état de lien correctes. Ceci affecte la capacité d'un partenaire à prendre en charge correctement ses clients quand un problèmes de lien survient.

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

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

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

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

Résolu dans Orchestrator version R5104-20230426-GA

La build R5104-20230426-GA d'Orchestrator a été publiée le 27/04/2023 et constitue la 4e build cumulative d'Orchestrator pour la version 5.1.0.

Cette build cumulative d'Orchestrator résout les problèmes importants ci-dessous depuis la 3e build cumulative R5103-20230315-GA d'Orchestrator.

  • Problèmes se produisant uniquement sur la nouvelle interface utilisateur d'Orchestrator et non sur l'interface utilisateur classique d'Orchestrator

    Orchestrator version 5.1.0.4 inclut un grand nombre de correctifs associés aux problèmes qu'un client peut rencontrer uniquement lors de l'utilisation de la nouvelle interface utilisateur et qui ne se produisent pas lors de l'utilisation de l'interface utilisateur classique. Le tableau ci-dessous répertorie tous ces correctifs avec une description des symptômes de chaque problème.

    Problèmes résolus de la nouvelle interface utilisateur uniquement

    Ticket

    Symptôme/Description

    Problème résolu n° 104785

    Lorsqu'un utilisateur se trouve sur la page Surveiller (Monitor) > Événements (Events) et clique sur le bouton Actualisation des événements (Events refresh), l'horodatage du tableau Événements (Events) n'est pas mis à jour et les événements les plus récents ne s'affichent pas dans le tableau, sauf si la page du navigateur Web est rechargée.

    Problème résolu n° 106327

    Lorsqu'un utilisateur se trouve sur la page Surveiller (Monitor) > Événements (Events) et configure un filtre pour les événements, certaines options de filtre sont manquantes et limitent le mode de filtrage des événements du dispositif Edge.

    Problème résolu n° 107071

    Lorsqu'un utilisateur se trouve sur la page Surveiller (Monitor) > Événements (Events) et sélectionne une fenêtre de temps suffisamment grande pour renvoyer plus de 5 millions d'événements, la page expire et ne se charge pas.

    Problème résolu n° 107980

    Lorsqu'un utilisateur se trouve sur la page Configurer (Configure) > Dispositif Edge (Edge) > Présentation (Overview), il ne peut pas modifier le nom d'un dispositif Edge, sauf s'il remplit également les données Contact et emplacement (Contact & Location) si les coordonnées locales ne sont pas renseignées.

    Problème résolu n° 108072

    Lorsqu'un utilisateur tente de configurer une interface Loopback avec la même adresse IP sur différents segments, Orchestrator empêche cette opération et affiche un message d'avertissement « Doit être unique » (Must be unique).

    Problème résolu n° 109284

    Lorsqu'un utilisateur ajoute un tunnel pour une destination non-SD-WAN (NSD) via un dispositif Edge de type Azure ou Zscaler, vous pouvez modifier les champs Type d'identification locale (Local Identification Type), Identification locale (Local Identification) et PSK.

    Problème résolu n° 109300

    Lorsqu'un utilisateur examine une zone d'Orchestrator dans laquelle une licence doit être configurée, seule la licence sélectionnée s'affiche. Orchestrator exclut toutes les autres options de licence lorsqu'une option est sélectionnée et que le correctif de ce problème inclut un nouveau bouton Effacer (Clear) à droite du menu déroulant Licence (License) pour permettre la sélection d'une autre option de licence différente.

    Problème résolu n° 109532

    Lorsque vous examinez la page Configurer (Configure) > Services réseau (Network Services), les adresses IP du DNS diffèrent sur la nouvelle interface utilisateur par rapport à l'interface utilisateur classique, car la nouvelle interface utilisateur affiche des champs différents.

    Problème résolu n° 109533

    Sur la page Configurer (Configure) > Dispositif Edge (Edge)> Périphérique (Device) > Connectivité (Connectivity) > VLAN, le serveur DHCP s'affiche comme étant Activé (Enabled) lorsqu'un état plus précis de Relais (Relay) doit s'afficher.

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

    Problème résolu n° 109788

    Lors de la configuration d'une destination non-SD-WAN, un utilisateur ne peut pas configurer un Sous-réseau du site (Site Subnet) avec une valeur 0.0.0.0/0. Orchestrator le déclare alors « Préfixe CIDR non valide » (Invalid CIDR Prefix).

    Problème résolu n° 109836

    Les routes statiques de la passerelle partenaire ne sont pas distribuées aux dispositifs Edge lors de la configuration de ces routes sur la nouvelle interface utilisateur. Ces routes doivent être distribuées aux dispositifs Edge connectés comme routes de cloud (Type = Cloud) et affichées dans un vidage de la table de routage, mais elles ne le sont pas.

    Problème résolu n° 109911

    Lors de la configuration d'une Business Policy dans la section Choix du lien (Link Steering) > Interfaces, vous ne pouvez pas sélectionner cette interface si le type d'overlay WAN est « Désactivé » (Disabled). La nouvelle interface utilisateur autorise les interfaces associées à l'overlay WAN qui sont détectées automatiquement ou définies par l'utilisateur uniquement.

    Problème résolu n° 110094

    Lors de la modification d'une interface du dispositif Edge et de l'ajout simultané d'un grand nombre de filtres à OSPF, la grille des filtres disparaît. Lorsqu'un nombre suffisant de filtres OSPF est ajouté pour que la pagination s'effectue dans la grille des filtres OSPF, la hauteur de la grille est définie sur 0. Un utilisateur ne peut alors ni modifier ni afficher la grille de filtres.

    Problème résolu n° 110330

    Les administrateurs partenaires et clients peuvent ne pas afficher l'onglet Paramètres globaux (Global Settings) > Autorisations de service (Service Permissions), même si leur rôle leur permet de le faire. Autorisations de service (Service Permissions) est l'emplacement de documentation de la personnalisation des rôles d'utilisateur.

    Problème résolu n° 111104

    Lorsqu'il examine la page Paramètres de service (Service Settings) > Gestion d'Edge (Edge Management) > Images logicielles et du microprogramme (Software & Firmware Images), l'utilisateur ne peut pas afficher tous les détails s'il développe une ligne en bas du tableau.

    Problème résolu n° 111407

    Lorsqu'un utilisateur se trouve sur la page Configurer (Configure) > Dispositif Edge (Edge) > Connectivité (Connectivity) > Interfaces, il n'est pas autorisé à configurer une interface définie par l'utilisateur sans ajouter également de lien WAN.

    Problème résolu n° 111444

    Lors de la configuration d'un service de sécurité cloud (CSS) avec un type Zscaler, l'utilisateur n'est pas autorisé à configurer l'URL de connexion Zscaler (Zscaler Login URL) avec une URL et reçoit le message Le nom de domaine complet n'est pas valide (FQDN is invalid). La valeur de l'URL de connexion n'est d'ailleurs pas envoyée à un serveur ni enregistrée.

    Problème résolu n° 111934

    Lors de la mise à jour d'un champ de destination non-SD-WAN via un dispositif Edge avec le type Zscaler, Orchestrator supprime le champ Groupe DH (DH Group).

    Problème résolu n° 111944

    Un super utilisateur opérateur ne peut ni modifier ni supprimer une Propriété système (System Property).

    Problème résolu n° 112094

    Lorsqu'un utilisateur modifie les informations d'identification d'un service de sécurité cloud (CSS) sur un segment non global, et que dans la même session, il passe à un segment global, les informations d'identification du CSS sont supprimées.

    Problème résolu n° 112201

    Si un utilisateur configure un service de sécurité cloud (CSS) via une API et définit le CSS sur Aucun (Vide), sous la configuration CSS de VMware Edge, le dispositif Orchestrator n'affiche aucune configuration. Toutefois, le CSS est actif et opérationnel dans les réponses de la base de données et de l'API du dispositif Edge. Vous ne pouvez pas utiliser un CSS dans cet état dans le cadre d'une Business Policy.

    Problème résolu n° 112224

    Lorsqu'un administrateur client disposant d'un rôle de super utilisateur, standard ou de support accède à Diagnostics, le lien de la page Bundles de diagnostics (Diagnostic Bundles) est absent, même si son rôle permet d'accéder à cette section. Par conséquent, un administrateur client ne peut pas générer (ni télécharger) un bundle de diagnostics, et ne peut pas générer et télécharger une capture de paquets.

    Problème résolu n° 112437

    Si un utilisateur ouvre plusieurs sessions Diagnostics à distance (Remote Diagnostics) pour le même dispositif Edge, la page peut ne pas se charger après l'ouverture d'un nombre suffisant de sessions.

  • Problème résolu 95631 : Lorsqu'un utilisateur accède à Surveiller (Monitor) > Services réseau (Network Services) > Sites du service de sécurité cloud (Cloud Security Service Sites) et tente de trier les événements selon l'heure de modification de l'état, la séquence de tri est incorrecte.

    Lorsqu'un utilisateur tente de les trier selon la colonne Heure de modification de l'état (State Change Time) du tableau CSS, le tri est incorrect, car les dates ne sont pas triées selon leur horodatage, mais selon la date d'analyse. Ce problème se produit sur l'interface utilisateur classique et la nouvelle interface utilisateur.

  • Problème résolu 106907 : Lorsqu'un client a configuré une destination non-SD-WAN (NSD) via un dispositif Edge qui est associée à une Business Policy, si un utilisateur utilise ultérieurement le remplacement du dispositif Edge (Edge Override) pour désactiver la NSD via le dispositif Edge, cette Business Policy n'est pas supprimée sur un dispositif VMware SASE Orchestrator utilisant la version 5.1.0.

    Orchestrator doit supprimer la Business Policy une fois que la NSD via le dispositif Edge est désactivée, car si la règle persiste, le trafic qui correspond à cette Business Policy est dirigé vers une destination inexistante, ce qui entraîne l'abandon de ce trafic.

  • Problème résolu 106929 : Un opérateur peut ne pas être en mesure d'attribuer une version logicielle à un profil d'opérateur sur VMware SASE Orchestrator à l'aide de la version 5.1.0.

    Orchestrator génère une erreur semblable à la suivante :

    Message d'erreur.

    Ce problème est dû au délai d'expiration d'Orchestrator dans la tentative d'ajout de l'image logicielle en raison de requêtes d'API de bases de données concurrentes. Ce problème est plus susceptible de se produire sur un dispositif Orchestrator hébergeant un grand nombre de dispositifs Edge comme c'est le cas sur les dispositifs Orchestrator hébergés sur VMware et peut survenir si vous utilisez la nouvelle interface utilisateur ou l'interface utilisateur classique.

    Sur un dispositif Orchestrator sans correctif pour ce problème, la seule solution consiste à augmenter la valeur du délai d'expiration pour les connexions à la base de données.

  • Problème résolu 107349 : Lorsque vous examinez Surveiller (Monitor) > Dispositif Edge (Edge) > Sources sur VMware SASE Orchestrator, certaines sources voire la totalité d'entre elles peuvent ne pas se résoudre et le message « Résolution impossible » (Unable to resolve) s'affiche.

    Ce problème n'est pas systématique et certains sites d'une entreprise cliente peuvent afficher les adresses IP et MAC des sources comme prévu. Ce problème est dû au fait qu'une table de base de données Orchestrator n'est pas mise à jour pour les noms de dispositifs Edge.

    Si un client rencontre ce problème sur un dispositif Orchestrator sans correctif pour ce problème, il peut désactiver le VPN cloud dans une fenêtre de maintenance, puis le réactiver pour forcer Orchestrator à récupérer les noms de dispositifs Edge appropriés.

  • Problème résolu 108363 : Lors de la mise à niveau d'un dispositif VMware SASE Orchestrator vers une version 5.x, les dispositifs VMware SD-WAN Edge qui déploient des services de sécurité cloud (CSS) comme Zscaler et qui disposent d'un contrôle de santé de niveau 7 (L7) également configuré peuvent subir une perte de trafic pendant environ 30 secondes à l'aide de ce CSS.

    Lorsqu'Orchestrator est mis à niveau, il déclenche une mise à jour de la configuration de tous les dispositifs Edge, ce qui peut entraîner l'arrêt de certains sites CSS avec le contrôle de santé L7 configuré jusqu'à ce que la configuration soit corrigée. Le problème est lié au Problème résolu n° 107302 qui corrige le problème sur le dispositif Edge. Le correctif ici empêche Orchestrator de déclencher les mises à jour de configuration des dispositifs Edge lors d'une mise à niveau et protège donc les dispositifs Edge qui ne disposent pas du correctif pour n° 107302.

  • Problème résolu 110946 : Un dispositif VMware SD-WAN Orchestrator utilisant la version 4.2.x ou antérieure risque d'échouer lors de la mise à niveau pour devenir un dispositif SASE Orchestrator à l'aide de la version 4.3.x ou ultérieure.

    Un dispositif Orchestrator de version 4.2.x ou antérieure ne nettoie pas le cache apt avant d'exécuter la routine apt update service lorsqu'Orchestrator est mis à niveau vers la version 4.3.x ou ultérieure. Par conséquent, la base de données MySQL redémarre pendant la mise à niveau et celle-ci échoue.

    Si vous effectuez la mise à niveau vers une version d'Orchestrator sans correctif pour ce problème, l'opérateur peut exécuter la commande rm -rf /var/lib/apt/lists/ avant la mise à niveau.

  • Problème résolu 111665 : Lors de la mise à jour d'un dispositif VMware SASE Orchestrator d'une version antérieure d'Orchestrator vers la version 5.1.0, la migration du périphérique client peut ne pas se terminer.

    Ce problème a une incidence sur la migration des données du périphérique client d'un dispositif Orchestrator utilisant MySQL vers un dispositif utilisant ClickHouse. Après la migration d'un certain nombre d'enregistrements, le processus de migration se termine prématurément.

  • Problème résolu 111946 : Un utilisateur ne distingue pas les chemins sur l'onglet Dispositif Edge (Edge) > Surveiller (Monitor) > Chemins (Paths) sur un dispositif VMware SASE Orchestrator lorsque la liste de peers est supérieure à 100.

    Lorsqu'un utilisateur accède à l'onglet Dispositif Edge (Edge) > Surveiller (Monitor) > Chemins (Paths), le serveur principal d'Orchestrator renvoie tous les enregistrements, même s'il en existe plus de 100. Cela est dû au fait que le serveur principal omet la contrainte de limite, qui est le nombre maximal d'enregistrements qui doivent être renvoyés. Les enregistrements renvoyés une fois la limite atteinte ne sont pas normalisés, car leur formatage n'est pas compatible avec l'interface utilisateur. Cela entraîne une erreur dans l'interface utilisateur. Orchestrator ne doit renvoyer que les enregistrements qui se trouvent dans la limite indiquée.

  • Problème résolu 112458 : Lorsqu'une nouvelle passerelle VMware SD-WAN Gateway est ajoutée à un pool de passerelles et qu'un rééquilibrage de passerelle est lancé, la nouvelle passerelle n'est pas redistribuée vers les dispositifs VMware SD-WAN Edge, même si les passerelles existantes sont surchargées.

    Le dispositif VMware SASE Orchestrator doit réattribuer plusieurs dispositifs Edge à la passerelle la moins chargée dans la même région géographique lorsqu'un rééquilibrage de passerelle est effectué. Avec ce problème, les dispositifs Edge conservent leur attribution de passerelle existante malgré la surcharge de cette passerelle attribuée.

  • Problème résolu 112885 : Un rééquilibrage de passerelle peut être déclenché pour les workflows non directement associés au déclenchement de celui-ci via l'interface utilisateur de VMware SASE Orchestrator.

    Le correctif ici résout le problème selon lequel les rééquilibrages de passerelle peuvent se produire pour les workflows en dehors de ce qui est prévu pour une entreprise dédiée. Un rééquilibrage de passerelle ne doit être déclenché que via l'interface utilisateur d'Orchestrator au niveau de l'opérateur uniquement.

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

Résolu dans Orchestrator version R5103-20230315-GA.

La build R5103-20230315-GA d'Orchestrator a été publiée le 15/03/2023 et constitue la 3e build cumulative d'Orchestrator pour la version 5.1.0.

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

  • Problème résolu 107587 : Un opérateur ne peut pas modifier les détails de l'utilisateur pour d'autres opérateurs ou pour les administrateurs de clients sur VMware SASE Orchestrator.

    Les opérateurs doivent avoir le privilège de modifier les détails de l'utilisateur sous Administration > Gestion des utilisateurs (User Management) pour un autre opérateur si leur rôle le permet et de modifier un administrateur de client si la délégation de gestion est activée. Avec ce problème, l'opérateur observe les détails de l'utilisateur en lecture seule sans pouvoir les modifier.

  • Problème résolu 107725 : Lorsqu'un utilisateur utilisant la nouvelle interface utilisateur de VMware SASE Orchestrator accède à Surveiller (Monitor) > Dispositifs Edge (Edges) > Distribution de mappage (Map Distribution), la carte affiche uniquement 20 dispositifs VMware SD-WAN Edge au maximum simultanément, mais pas tous les dispositifs Edge qu'un client a déployés.

    Ce problème affecte les clients qui déploient plus de 20 dispositifs Edge, car la Distribution de mappage (Map Distribution) de la nouvelle interface utilisateur n'affiche que 20 dispositifs Edge simultanément dans la liste des dispositifs Edge du client. Lorsque l'utilisateur clique sur la page suivante de la liste, la carte affiche uniquement ces dispositifs Edge sur cette page. Aucune option ne permet de répertorier tous les dispositifs Edge d'une entreprise cliente.

  • Problème résolu 108533 : Lorsqu'un utilisateur accède à Paramètres de service (Service Settings) > Gestion d'Edge (Edge Management) > Configurer les mises à jour (Configure Updates), le texte d'explication des paramètres n'est pas clair dans la nouvelle interface utilisateur de VMware SASE Orchestrator.

    Le nom du paramètre Désactiver les mises à jour de la configuration du dispositif Edge (Disable Edge Configuration Updates) contredit la fonction réelle du paramètre. Avec ce correctif, il passe à Activer les mises à jour de la configuration du dispositif Edge (Enable Edge Configuration Updates) pour s'aligner sur la fonction et le texte d'explication.

  • Problème résolu 108833 : Si un utilisateur modifie un filtre BGP sur un segment non global sur la nouvelle interface utilisateur de VMware SASE Orchestrator, le dispositif Orchestrator remplace ce changement de filtre BGP sur le segment global par ce nouveau paramètre.

     Pour un client utilisant BGP sur plusieurs segments avec des paramètres uniques sur chacun d'eux, ce problème peut entraîner une panne de réseau pour les utilisateurs utilisant le segment global dans lequel les paramètres BGP sont remplacés. Ce problème ne s'observe pas lors de l'utilisation de l'interface utilisateur classique.

  • Problème résolu 109064 : Un utilisateur peut configurer le même SSID (Service Set Identifier) sur deux interfaces Wi-Fi différentes pour un dispositif VMware SD-WAN Edge si l'utilisateur configure le filtre MAC sur l'une et non sur l'autre interface Wi-Fi.

    La configuration du même SSID sur WLAN1 et WLAN2, l'un avec le filtre MAC activé et l'autre avec le filtre MAC désactivé ou avec une liste d'adresses MAC autorisées différente sur chaque interface, ne doit pas être autorisée par VMware SASE Orchestrator, car cela permet la connexion des adresses MAC non approuvées.

Résolu dans Orchestrator version R5102-20230222-GA.

La build R5102-20230222-GA d'Orchestrator a été publiée le 24/02/2023 et constitue la 2e build cumulative d'Orchestrator pour la version 5.1.0.

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

  • Problème résolu 40584 : Lorsqu'un utilisateur examine la page Surveiller (Monitor) > Dispositif Edge (Edge) > Sources sur VMware SASE Orchestrator, il peut observer que même si de nouveaux périphériques clients ont été ajoutés à un dispositif VMware SD-WAN Edge, Orchestrator n'affiche pas le dernier périphérique client lorsque le mode de visibilité IP (IP Visibility) est utilisé.

    Ce problème peut se produire lorsque le Mode de visibilité du dispositif Edge est configuré en tant que Visibilité par adresse IP (Visibility by IP Address). Ce problème est dû au fait qu'Orchestrator ne traite pas correctement les dernières informations sur le client pour le dispositif Edge lors de l'utilisation du mode Adresse IP (IP Address) et affiche donc uniquement l'ancien client et son adresse IP.

  • Problème résolu 105610 : Lorsqu'un utilisateur tente de créer un groupe d'objets IPv4 ou tente de mettre à jour un groupe d'objets IPv4 existant qui inclut un masque wildcard qui commence par « 255 » et se termine par « 0 » (par exemple, 255.0.1.0), VMware SASE Orchestrator n'autorise pas ce masque wildcard et génère une erreur, même s'il s'agit d'une expression wildcard valide et qu'elle doit être autorisée.

    À partir de la version 5.0.x, les dispositifs Orchestrator ne disposent pas de la validation des masques wildcard dans les groupes d'objets et, par conséquent, génèrent une erreur lorsqu'un utilisateur configure un masque wildcard pour une seule entité.

  • Problème résolu 106159 : Un dispositif VMware SASE Orchestrator exécutant les versions 5.1.0.0 et 5.1.0.1 n'autorise pas les utilisateurs natifs à créer des jetons d'API lorsque l'authentification est configurée comme Single Sign-On (SSO) et que le fournisseur d'identité (IdP) correspondant ne prend pas en charge le point de terminaison d'introspection.

    La version 5.1.0.0 ajoute une vérification du point de terminaison d'introspection IdP lors de la validation de la création du jeton d'API. Cette vérification ne différencie pas les utilisateurs natifs des utilisateurs non natifs et, tant que SSO est configuré pour l'authentification, Orchestrator vérifie si le fournisseur d'identité prend en charge le point de terminaison d'introspection. Dans le cas contraire, la validation empêche alors les utilisateurs natifs et non natifs de créer des jetons d'API. Cette condition est vraie pour les utilisateurs opérateurs et les administrateurs partenaires.

  • Problème résolu 106242 : Un utilisateur accédant à la page Diagnostics > Diagnostics à distance (Remote Diagnostics) sur VMware SASE Orchestrator peut se déconnecter de manière inattendue de la page Diagnostics à distance (Remote Diagnostics) lors d'un diagnostic du dispositif Edge.

    Lorsqu'un utilisateur rencontre ce problème, cela est dû au fait qu'Orchestrator a atteint une limite au nombre de connexions possible et déconnecte les utilisateurs de diagnostics à distance pour garantir un fonctionnement normal. Ce problème est dû au fait qu'Orchestrator ne libère pas par erreur les connexions à la base de données une fois qu'elles ne sont plus nécessaires. Cela entraîne le déclenchement de comportements de la limite de connexions par Orchestrator.

  • Problème résolu 106592 : Sur un dispositif VMware SASE Orchestrator exécutant les versions 5.1.0.0 et 5.1.0.1, un client utilisant les API peut observer les symptômes suivants : a) Les jetons d'API actifs sont révoqués par Orchestrator et b) Les services tels qu'APIv2 ne fonctionnent plus.

    La version 5.1.0.0 ajoute une nouvelle tâche principale appelée batchRevokeApiTokenForInactiveSsoUsers qui s'exécute toutes les 6 heures pour révoquer les jetons d'API émis précédemment pour les utilisateurs Single Sign-On (SSO) inactifs. Les anomalies dans la tâche principale entraînent une révocation par erreur de tous les jetons d'API sur le dispositif Orchestrator, quels que soient les destinataires de la création des jetons.

    Sans le correctif, un administrateur client disposant d'un rôle de super utilisateur ou d'administrateur partenaire doit supprimer manuellement les utilisateurs du fournisseur d'identité (IdP) inactifs d'Orchestrator pour empêcher l'accès non autorisé via des jetons d'API.

  • Problème résolu 106806 : Lorsqu'un dispositif VMware SASE Orchestrator est mis à niveau vers la version 5.1.0, les clients connectés à Orchestrator peuvent observer des interruptions du trafic client.

    Orchestrator crée une version du module de paramètres du périphérique dans le cadre de sa mise à niveau vers la version 5.1.0. Orchestrator transmet ensuite cette nouvelle version des paramètres du périphérique à tous les dispositifs Edge connectés, ce qui risque d'être perturbateur, car certaines modifications des paramètres du périphérique peuvent déclencher un redémarrage du service Edge, ce qui entraîne une interruption du trafic client de 10 à 15 secondes. Le correctif de ce problème vérifie qu'Orchestrator ne transfère pas une version des paramètres du périphérique mise à jour à tous les dispositifs Edge connectés lorsqu'il est mis à niveau vers la version 5.1.0.

  • Problème résolu 107410 : Pour un administrateur partenaire utilisant la nouvelle interface utilisateur sur VMware SASE Orchestrator, l'utilisateur observe qu'il ne peut pas faire défiler le menu déroulant qui répertorie les images logicielles lors d'une tentative d'attribution d'une image logicielle à l'un des clients du partenaire.

    Cela implique que, sauf si le partenaire remarque l'image logicielle qu'il souhaite sur l'affichage initial des images lorsque le menu déroulant est ouvert, il ne pourra pas faire défiler l'écran vers le bas pour trouver l'image souhaitée si elle se trouve tout en bas. Les utilisateurs opérateurs n'ont aucun problème à effectuer cette opération et l'administrateur partenaire peut toujours faire défiler l'interface utilisateur classique lors de l'attribution d'une image logicielle à un client.

  • Problème résolu 107637 : Un client disposant d'un grand nombre de dispositifs Edge VMware peut constater en accédant à Configurer (Configure) > Dispositifs Edge (Edges) sur l'interface utilisateur classique de VMware SASE Orchestrator que la page ne se charge pas.

    Ce problème se produit sur l'interface utilisateur classique et la page expire avec le message « Une erreur inattendue s'est produite » (An unexpected error has occurred). Un utilisateur ne rencontre pas ce problème lors de l'utilisation de la nouvelle interface utilisateur.

    Écran d'erreur.

    Lors de la résolution du problème, un opérateur constate dans les journaux d'Orchestrator que la méthode enterprise/getEnterpriseEdgeList échoue avec l'erreur suivante :

    2023-02-06T17:21:05.412Z - error: [[email protected]] [24775] API Invocation error for enterprise/getEnterpriseEdgeList: { code: undefined, message: 'Internal error' }

    Ce problème est dû à une API Orchestrator qui récupère la liste des dispositifs Edge d'un client dans des scénarios tels que Configurer (Configure) > Dispositifs Edge (Edges). Dans l'interface utilisateur classique, cette API est utilisée de manière à entraîner son expiration, en particulier lorsqu'un grand nombre de dispositifs Edge doit être récupéré (par exemple, au moins cinq cents dispositifs Edge).

  • Problème résolu 107885 : Pour tout utilisateur de la nouvelle interface utilisateur de VMware SASE Orchestrator, la page Configurer (Configure) > Présentation (Overview) peut ne pas se charger pour certains dispositifs VMware SD-WAN Edge.

    Ce problème n'est pas constant et la page Configurer (Configure) > Présentation (Overview) peut se charger pour certains dispositifs Edge. Ce problème se déclenche lorsque le module QoS du dispositif Edge n'est pas renseigné avec des informations de segment.

    Sur un dispositif Orchestrator sans correctif pour ce problème, un utilisateur peut configurer une Business Policy de test qui n'a aucune incidence sur le trafic utilisateur et l'enregistrer, auquel cas la page Présentation (Overview) se charge.

  • Problème résolu 108074 : Lorsqu'un utilisateur fait défiler vers le bas la zone d'informations du dispositif Edge sur l'écran Surveiller (Monitor) > dispositif Edge (Edge), la description est manquante lors de l'examen de ces informations dans la nouvelle interface utilisateur d'un dispositif VMware SASE Orchestrator.

    Sur l'écran de l'interface utilisateur classique pour Surveiller (Monitor) > Dispositif Edge (Edge), l'écran déroulant d'informations sur le dispositif Edge affiche la description configurée :


    Dans l'écran Nouvelle interface utilisateur (New UI) pour Surveiller (Monitor) > Dispositif Edge (Edge), l'écran déroulant d'informations sur le dispositif Edge n'affiche pas la description configurée :


    Un utilisateur peut configurer la page Description du dispositif Edge sur la page Configurer (Configure) > Dispositif Edge (Edge) > Présentation (Overview).

  • Problème résolu 108309 : Sur la nouvelle interface utilisateur d'un dispositif VMware SASE Orchestrator utilisant la version 5.1.0, lorsqu'un utilisateur tente d'associer un dispositif VMware SD-WAN Edge à une destination non-SD-WAN (NSD) à l'aide du remplacement du dispositif Edge (Edge Override), l'option de configuration du tunnel ne s'affiche pas.

    L'option de configuration du tunnel doit s'afficher comme dernière colonne de l'écran sous la forme Action avec un symbole + dans ce problème indiquant que le symbole + est manquant.


    Ce problème est limité aux actions spécifiques au dispositif Edge. Si un client ajoute une NSD via un profil utilisé par le dispositif Edge (plutôt que d'utiliser le remplacement du dispositif Edge [Edge Override]), l'option Action + s'affiche correctement.


Résolu dans Orchestrator version R5101-20221220-GA.

La build R5101-20221220-GA d'Orchestrator a été publiée le 20/12/2022 et constitue la 1ère build cumulative d'Orchestrator pour la version 5.1.0.

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

  • Problème résolu 100133 : Un dispositif VMware SASE Orchestrator peut rencontrer des problèmes de performances.

    Lorsqu'un client configure un grand nombre de règles de Business Policy en les associant ensuite à un cluster Hub Edge, Orchestrator rencontre des problèmes de performances chaque fois qu'il doit transférer ces configurations vers les dispositifs Edge de cette entreprise.

  • Problème résolu 101835 : La section VPN cloud (Cloud VPN) n'est pas disponible dans la nouvelle interface utilisateur d'Orchestrator si l'utilisateur sélectionne un segment non global dans lequel la section VPN cloud (Cloud VPN) est configurée.

    Dans la nouvelle interface utilisateur d'Orchestrator, sur la page des paramètres Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device), la section VPN cloud (Cloud VPN) n'est pas disponible si l'utilisateur sélectionne un segment non global dans lequel la section VPN cloud (Cloud VPN) est configurée.

  • Problème résolu 102806 : Le client ne peut pas modifier la configuration du transfert de la passerelle partenaire au niveau de chaque passerelle.

    Ce problème se produit lorsqu'un client configure le transfert de la passerelle partenaire lors d'une mise à niveau.

  • Problème résolu 103622 : L'utilisateur opérateur peut observer le message d'erreur suivant : « Vous n'êtes pas autorisé à accéder à ces données » (You don't have permission to access this data) lorsque vous tentez d'accéder à certaines pages de VMware SASE Orchestrator.

    Ce problème s'observe dans la nouvelle interface utilisateur d'Orchestrator lorsqu'un utilisateur opérateur tente d'accéder à la page Gestion des utilisateurs opérateurs ou partenaires (Operator or Partner User Management), après avoir consulté les pages Paramètres globaux (Global Settings), Cloud Web Security ou Secure Access sous un client.

Résolu dans Orchestrator version R5100-20221202-GA.

La version R5100-20221202-GA d'Orchestrator a été publiée le 08/12/2022 et résout les problèmes suivants depuis Orchestrator version R5011 -20221129-GA.

Note:

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

  • Problème résolu 91407 : La superposition WAN définie par l'utilisateur est configurée en tant que liaison de sauvegarde. Le dispositif VMware SASE Orchestrator exécutant la version 5.0.x affiche la liaison comme étant active sous Surveiller (Monitor) > Dispositif Edge (Edge) lorsque la liaison est en mode de sauvegarde.

    Il s'agit d'un problème d'affichage uniquement et la fonctionnalité de liaison WAN de sauvegarde fonctionne correctement. Ce problème est dû au fait qu'Orchestrator ne stocke pas correctement les valeurs du mode de liaison pour le dispositif Edge et entraîne l'affichage d'un état incorrect.

  • Problème résolu 91393 : Pour un client qui collecte des données à partir du dispositif Edge à l'aide de Syslog ou Telnet, l'utilisateur peut observer deux noms pour la même application dans les données NetFlow du dispositif VMware SD-WAN Edge.

    Ce problème se produit lorsqu'il existe des applications pour lesquelles la valeur displayName dans le fichier linguistique (appids_en_us.json) est différente de la valeur displayName dans le fichier d'applications (applications.json). Étant donné que la valeur displayName du fichier applications.json est utilisée côté Edge, cela ne devrait pas changer.

    Ce problème se produit, car la valeur displayName du fichier applications.json a été remplacée par la valeur displayName du fichier appids_en_us.json dans le cadre d'une réponse API. En outre, chaque fois que les données de carte d'application sont mises à jour, elles mettent à jour chaque valeur displayName de carte d'application, même lorsque l'utilisateur ne l'a pas modifiée et qu'elle est transférée vers le dispositif Edge.

  • Problème résolu 12132 : Lors de la configuration d'une route statique sur VMware SASE Orchestrator, l'interface utilisateur avertit qu'un redémarrage du service Edge ne se produit pas réellement.

    Lors de la modification de la configuration sur une route statique et de l'enregistrement des modifications, l'interface utilisateur d'Orchestrator vous avertit qu'un redémarrage du dispositif Edge et une interruption de service se produiront. Ce message n'est pas valide et aucun redémarrage du service Edge n'est associé à la modification d'une configuration de route statique. Le correctif supprime l'avertissement trompeur.

  • Problème résolu 36058 : Une liaison WAN configurée en tant que liaison de sauvegarde peut s'afficher en gris sur la page Surveiller (Monitor) > Présentation (Overview) de l'interface utilisateur de VMware SASE Orchestrator lorsque la liaison est en réalité inactive.

    L'écran ressemble à ce qui suit :


    Lorsque vous examinez la page Surveiller (Monitor) > Dispositif Edge (Edge) > Présentation (Présentation), l'état du lien de sauvegarde affiche un état exact.

  • Problème résolu 52952 : L'interface utilisateur de VMware SASE Orchestrator permet à un utilisateur de configurer des entrées non valides pour le préfixe de chemin AS.

    L'interface utilisateur d'Orchestrator n'inspecte pas une valeur de préfixe de chemin AS non valide. Un utilisateur peut entrer le préfixe de chemin AS avec des valeurs qui incluent une virgule, et l'interface utilisateur accepte cette configuration non valide pour le processus de routage Edge. La configuration non valide n'est pas appliquée et l'utilisateur ne reçoit aucun commentaire, par exemple un avertissement, un message d'erreur ou une astuce concernant la configuration non valide.

  • Problème résolu 53740 : Lors de la configuration d'une règle de pare-feu sur l'interface utilisateur de VMware SASE Orchestrator, un utilisateur ne peut pas configurer une valeur de protocole pour un protocole qu'il souhaite faire correspondre.

    Orchestrator autorise uniquement TCP/UDP/ICMP/GRE dans les critères de correspondance de protocole et n'autorise pas les valeurs de protocole comprises entre 0 et 255. La modification permet à un utilisateur de configurer une règle de pare-feu correspondante et sous Destination, l'utilisateur sélectionne Autre (Other) dans le menu Protocole (Protocol), puis entre une valeur comprise entre 0 et 255.

    Note:

    Bien qu'un utilisateur puisse entrer une valeur comprise entre 0 et 255, les valeurs de protocole 144 à 255 sont considérées comme étant réservées ou non attribuées conformément à la documentation Numéros de protocole Internet attribués par IANA.

  • Problème résolu 68347 : VMware SASE Orchestrator affiche par erreur un événement Zscaler IPsec pour le tunnel GRE en tant qu'événement de tunnel IPsec Edge sur la page Alertes.

    Les alertes ne doivent pas être générées pour les événements de tunnel GRE.

  • Problème résolu 70987 : Un utilisateur peut ne pas être en mesure de supprimer un dispositif VMware SD-WAN Edge du dispositif VMware SASE Orchestrator.

    Les dispositifs Edge sont hors ligne, mais ne sont pas mis à jour pour être déconnectés. Ils restent cependant dans un état dégradé et ne sont donc pas éligibles pour la suppression.

  • Problème résolu 72444 : Lorsqu'un utilisateur configure des BGP Neighbors IPv4 et IPv6 pour un dispositif VMware SD-WAN Edge, puis tente de désactiver les paramètres BGP à l'aide du curseur Activé/Désactivé (On/Off), la configuration n'est pas enregistrée, et l'interface utilisateur de VMware SASE Orchestrator indique « Aucune modification » (No Changes).

    Dans le cas rare où un utilisateur configure le paramètre BGP, mais désactive également BGP, les actions de l'utilisateur ne sont pas enregistrées pour les paramètres BGP comme elles le devraient.

  • Problème résolu 73481 : Lorsque plusieurs passerelles VMware SD-WAN Gateway sont déployées au même emplacement, un opérateur peut observer qu'une passerelle est utilisée par la plupart des dispositifs VMware SD-WAN Edge alors que les autres passerelles sont sous-utilisées, ce qui peut entraîner des problèmes de performances sur la passerelle entièrement utilisée.

    En raison de ce problème, une passerelle sera utilisée à 90 % tandis qu'une autre au même emplacement sera utilisée à 10 % avec des ressources libres. Les attributions de passerelles principale et secondaire pour les dispositifs Edge doivent prendre en compte la charge existante sur les passerelles. Si ce n'est pas le cas, une passerelle est surchargée en tant que passerelle principale alors qu'une passerelle secondaire dispose d'une capacité inutilisée importante.

  • Problème résolu 75175 : Lorsqu'un administrateur client tente d'accéder à la page Informations sur la passerelle sur VMware SASE Orchestrator, la page échoue avec une erreur.

    Une fois la migration d'une passerelle terminée, le message d'erreur suivant s'affiche sous Surveiller (Monitor) > Dispositif Edge (Edge) > Afficher (View) (sous Passerelle) : Erreur lors du chargement des informations sur la passerelle (Error Loading Gateway info)


    Les administrateurs clients ne sont pas censés être en mesure d'accéder à la page Informations sur la passerelle, mais lorsqu'ils tentent d'y accéder en raison de leur niveau de privilège, les sections renvoient des erreurs.

  • Problème résolu 76091 : Un utilisateur peut observer que lors de la modification d'un sous-réseau sur l'écran Configurer (Configure) > Périphérique (Device), l'écran se fige.

    Si vous cliquez sur le bouton Réinitialiser (Reset) ou que vous passez le dispositif Edge vers « Sorties VPN admissibles » (Eligible VPN Exits), puis que l'utilisateur clique sur Envoyer (Save) pour un sous-réseau qui n'a pas de routes apprises, l'interface utilisateur se fige avec l'icône de chargement qui tourne indéfiniment.


     

    Ce problème, qui est dû à l'absence de la baie learnedRoute dans ces sous-réseaux, déclenche un échec de l'interface utilisateur.

  • Problème résolu 76182 : Lorsque vous sélectionnez certains intervalles de temps sur la page Surveiller (Monitor) > Dispositif Edge (Edge) de l'interface utilisateur de VMware SASE Orchestrator, Orchestrator peut renvoyer des données incomplètes.

    Lorsqu'une requête utilisateur utilise des intervalles qui sont des multiples de 5, par exemple 12:00:00 - 13:00:00, le serveur principal n'envoie que 11 échantillons de 5 minutes, au lieu des 12 échantillons appropriés en raison d'un problème avec l'API de statistiques de liaison Edge.

  • Problème résolu 77538 : Lorsqu'une entreprise cliente est migrée d'un dispositif VMware SASE Orchestrator vers une autre instance d'Orchestrator, le client peut observer des profils d'opérateur et des images logicielles Edge en double.

    Non seulement les profils d'opérateur en double sont source de confusion pour le client, mais ils pointent toujours vers l'ancien dispositif Orchestrator. Par conséquent, un dispositif Edge utilisant un signal de pulsation est utilisé sur le mauvais dispositif Orchestrator, le dispositif Edge étant alors marqué comme hors service et n'obtenant pas les mises à jour de la configuration.

  • Problème résolu 79383 : Lorsqu'une modification est appliquée à la configuration dans Configurer (Configure) > Périphérique (Device), un utilisateur peut voir un message d'erreur, mais pas le nom du segment dans lequel l'erreur s'est produite.

    Par exemple, lors du basculement d'une interface Edge de routée à commutée au niveau du profil, un utilisateur voit une chaîne « object.segment.name » au lieu du nom du segment lorsqu'une erreur se produit dans les paramètres du périphérique.


    Si l'entreprise cliente utilise plusieurs segments, le dépannage devient très difficile lorsque le segment qui comporte l'erreur n'est pas clairement désigné.

  • Problème résolu 80445 : Lors de la configuration d'OSPF sur VMware SASE Orchestrator, un utilisateur peut observer que l'ID de zone OSPF autorise les entrées en double entre l'adresse IP et le numéro, et que la valeur de l'ID de zone OSPF « 0 » est autorisée comme ID valide.

    Orchestrator ne recherche pas les entrées en double par rapport aux adresses IP de type format et au numéro pour les ID de zone. En outre, il autorise la valeur « 0 » en tant qu'ID de zone OSPF valide. Par conséquent, l'utilisateur peut configurer et publier par erreur une configuration OSPF non valide avec les effets négatifs qui en résultent.

  • Problème résolu 81364 : Lors de l'utilisation de la nouvelle interface utilisateur d'Orchestrator pour configurer les interfaces VMware SD-WAN Edge, les paramètres de vitesse et de duplex ne sont pas mis à jour pour les interfaces acheminées.

    Sur un dispositif Orchestrator sans correctif pour ce problème, l'utilisateur doit utiliser le dispositif Orchestrator classique pour configurer les paramètres de vitesse et de duplex pour l'interface routée d'un dispositif Edge.

  • Problème résolu 81366 : Lors de l'utilisation de la nouvelle interface utilisateur d'Orchestrator pour configurer un site client à l'aide de la haute disponibilité, les modifications ne sont pas enregistrées pour l'intervalle de sonde APR sous les valeurs LOS.

    L'intervalle de sonde APR révisé sous Détection LoS (LoS Detection) n'affiche pas les valeurs configurées pour le dispositif Edge HA. Sur une instance d'Orchestrator sans correctif pour ce problème, les valeurs de sonde APR doivent être configurées sur le dispositif Orchestrator classique.

  • Problème résolu 83342 : Lorsque vous tentez de créer un rapport avec un trop grand nombre de dispositifs Edge, VMware SASE Orchestrator envoie un message d'erreur qui n'explique pas pourquoi le rapport a échoué.

    La génération d'un rapport qui renvoie des erreurs n'affiche pas les détails de l'erreur dans l'interface utilisateur et empêche l'utilisateur de corriger les causes de l'échec.


    Si nécessaire, les détails manquants seront fournis dans les données du journal de service sur un dispositif Orchestrator sans le correctif.

    S/O

  • Problème résolu 83345 : Si la tentative de création d'un rapport échoue sur VMware SASE Orchestrator en raison de l'échec du délai d'expiration, l'interface utilisateur n'affiche pas l'erreur de validation.

    Ce ticket est lié au problème 83342 et, dans les deux cas, les journaux ne sont pas suffisamment détaillés pour déboguer le problème. La différence ici est la cause du problème ; par exemple, la génération d'un rapport sans dispositif Edge peut également entraîner l'expiration du rapport sans explication de l'erreur.

  • Problème résolu 83694 : Un utilisateur se connecte à l'interface utilisateur locale d'un dispositif VMware SD-WAN Edge. VMware SASE Orchestrator ne consigne pas cette action ni ne l'affiche dans Surveiller (Monitor) > Événements (Events).

    Les administrateurs client ne sont pas informés des connexions des utilisateurs locaux à l'interface utilisateur locale d'un dispositif Edge.

  • Problème résolu 84064 : Pour un client qui déploie un Hub virtuel Microsoft Azure, il est possible de configurer BGP sur VMware SASE Orchestrator.

    BGP n'est pas officiellement pris en charge sur le « Hub virtuel Microsoft Azure », ce qui est automatisé. Cependant, les utilisateurs sont autorisés à configurer BGP sur Orchestrator, et si un utilisateur configure l'automatisation Azure avec BGP, les tunnels sont acheminés vers la passerelle et le site Azure ne transmet pas le trafic.


  • Problème résolu 88811 : Sur un dispositif VMware SASE Orchestrator utilisant la version 5.0.x, un super utilisateur opérateur ne peut pas créer de jetons d'API pour les utilisateurs clients, même s'ils disposent de privilèges délégués.

    Ce problème est dû au fait que le super utilisateur opérateur ne dispose pas du privilège CREATE ENTERPRISE_API_TOKEN. Par conséquent, l'opérateur ne peut pas créer, lire ou révoquer des jetons d'API pour d'autres utilisateurs.

  • Problème résolu 88845 : Lorsqu'un utilisateur tente de supprimer des interfaces d'une liste VLAN d'entreprise et enregistre les modifications sur un dispositif VMware SASE Orchestrator à l'aide de l'interface utilisateur classique, Orchestrator ne supprime pas les interfaces.

    Lors de l'enregistrement des modifications de cette action, Orchestrator ignore la modification de la configuration, car le format de données JSON ne correspond pas au format de données de l'interface utilisateur classique.

  • Problème résolu 88910 : Sur une instance de VMware SASE Orchestrator exécutant la version 4.5.1 ou 5.0.x, un utilisateur ne peut pas exécuter un test de débit de lien WAN pour un dispositif VMware SD-WAN Edge à l'aide de Diagnostics à distance (Remote Diagnostics) > Test de débit de lien WAN (WAN Link Speed Test).

    Lors de la tentative d'utilisation du diagnostic de test de débit de lien WAN, l'utilisateur ne pourra pas choisir une interface pour le test de débit, car il n'existe aucun menu déroulant pour les interfaces présentes.

    Sur un dispositif Orchestrator sans correctif pour ce problème, si un utilisateur souhaite forcer un test de bande passante pour un lien WAN, l'utilisateur peut modifier la méthode de mesure de bande passante pour ce lien WAN afin de résoudre le problème, ce qui déclenche automatiquement un nouveau test. Cette opération peut s'effectuer comme suit :

    1. Dans l'interface utilisateur d'Orchestrator pour un dispositif Edge particulier, accédez à Configurer (Configure) > Périphérique (Device) et faites défiler l'écran vers le bas jusqu'à l'option Paramètres WAN (WAN Settings).

    2. Pour tester à nouveau le lien WAN, sélectionnez Modifier (Edit) pour le mesurer à nouveau, puis sélectionnez Avancé (Advanced) pour afficher les paramètres supplémentaires.

    3. Dans le menu Mesure de bande passante (Bandwidth Measurement), remplacez la méthode de mesure de la bande passante actuelle par une autre (par exemple, si le lien utilise le mode rafale [Burst Mode], passez à Démarrage lent [Slow Star] ou vice versa) et cliquez sur Mettre à jour la liaison (Update Link), puis sur Enregistrer les modifications (Save Changes) en haut de la page Périphérique (Device).

    4. Une fois qu'une mesure a été effectuée sur le lien WAN, redéfinissez la méthode de mesure sur la méthode d'origine pour garantir la mesure la plus précise du lien WAN correspondant. Cela déclenche un test de bande passante supplémentaire.

  • Problème résolu 88998 : Un utilisateur ne peut pas cloner une Business Policy ou une règle de pare-feu sur un dispositif VMware SASE Orchestrator exécutant la version 5.0.x à l'aide de l'interface utilisateur classique.

    Dans la version 5.0.x de l'interface utilisateur classique d'Orchestrator, les options IPv6 et Mixte (IPv4 et IPv6) étaient désactivées pour la règle de Business Policy Edge. Cependant, les utilisateurs ont pu les utiliser en cas de clonage de règles existantes, mais avec pour résultat un message d'erreur.

    Ce problème ne se produit pas sur la nouvelle interface utilisateur d'Orchestrator et un utilisateur peut résoudre ce problème à l'aide de la nouvelle interface utilisateur.

  • Problème résolu 91231 : Pour un dispositif VMware SASE Orchestrator déployé avec une topologie de récupération d'urgence, la configuration initiale de la réplication de récupération d'urgence peut échouer si une tâche de troncature de table volumineuse est déclenchée lors de l'étape d'importation de tables volumineuse du processus de récupération d'urgence.

    L'importation en arrière-plan des statistiques dure plus de 24 heures. Cette tâche est en conflit avec les tâches de troncature automatisées qui s'exécutent quotidiennement. La tâche tronque les anciennes partitions des grandes tables qui sont également répliquées sur le serveur MySQL en veille.

    Toutefois, entre les processus, l'importation des données de MySQL peut être en cours pour la même table, ce qui entraîne l'échec de la réplication et l'échec de ce processus de récupération d'urgence global.

    Si ce problème survient sur un dispositif Orchestrator sans le correctif, le processus de récupération d'urgence peut être démarré après l'heure de changement de jour UTC. Cependant, cela ne garantit pas la prévention lorsqu'Orchestrator est volumineux et que la récupération d'urgence peut prendre plus de 24 heures.

  • Problème résolu 93846 : Pour les partenaires et les opérateurs gérant l'inventaire des dispositifs Edge à l'aide de ZTP, lorsqu'un utilisateur tente de réattribuer un dispositif VMware SD-WAN Edge à un autre client qui était précédemment attribué à un client, puis supprimé, le dispositif VMware SASE Orchestrator renvoie l'erreur « Le dispositif Edge est introuvable » (Edge is not found).

    Orchestrator détermine que le dispositif Edge n'existe pas, car le dispositif Edge logique ne s'affiche pas après sa suppression d'une entreprise cliente. Un utilisateur ne peut donc pas le réattribuer à un autre client.

Problèmes connus

Problèmes connus liés au dispositif Edge/à la passerelle

Problèmes ouverts dans la version 5.1.0.

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

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

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

  • Problème 115136 : un client peut observer une augmentation progressive de l'utilisation de la mémoire sur un dispositif VMware SD-WAN Edge dans une entreprise cliente qui utilise BGP pour le routage.

    Le démon BGP du dispositif Edge entraîne une fuite progressive de mémoire sur le dispositif Edge sur plusieurs jours et peut la provoquer même lorsque BGP n'est pas configuré pour ce dispositif Edge. Si la fuite de mémoire se poursuit pendant une période suffisante pour amener l'utilisation de la mémoire du dispositif Edge au-delà du seuil critique de 60 % de la RAM disponible pendant plus de 90 secondes, le dispositif Edge redémarre son service de manière défensive pour résoudre la fuite, ce qui peut entraîner une interruption du trafic client pendant 10 à 15 secondes.

    Solution : La seule correction en l'absence de correctif Edge consiste à redémarrer le processus BGP en l'arrêtant ou à effectuer de manière préventive un basculement HA/redémarrage du service Edge dans une fenêtre de service appropriée.

  • Problème 117037 : pour un client utilisant une topologie Hub/Spoke dans laquelle plusieurs liens WAN sont utilisés pour envoyer et recevoir le trafic du dispositif Spoke Edge vers le dispositif Hub Edge, les clients peuvent observer des performances inférieures à celles attendues pour le trafic dirigé par les business policies, car les liens WAN n'agrègent pas la bande passante du lien WAN.

    SD-WAN utilise un compteur pour comptabiliser le nombre de paquets mis en mémoire tampon dans une file d'attente de reséquencement. Ce compteur, géré par peer, permet de s'assurer que seuls 4 000 paquets sont mis en mémoire tampon par peer. Sous certaines conditions, ce compteur peut devenir négatif. Avant la version 4.2.x, lorsque ce compteur devenait négatif, le compteur respectif était immédiatement réinitialisé à 0 après le vidage des paquets dans la file d'attente de reséquencement. Cependant, à partir de la version 4.3.x, ce compteur est mis à jour automatiquement afin de rester dans les limites attendues.

    En raison de ce changement de comportement, il peut arriver que la comptabilité des compteurs soit incorrecte et que la file d'attente de reséquencement reste à un nombre très élevé, forçant SD-WAN à vider chaque paquet. Cette action empêche l'agrégation de bande passante, mais peut également réduire l'efficacité des flux qui se trouveraient autrement sur un lien unique.

    Solution : Sur les dispositifs Edge sans correctif pour ce problème, la solution consiste à configurer des business policies qui dirigent le trafic correspondant vers un lien obligatoire unique.

Problèmes connus d'Orchestrator

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