Mise à jour le 8 juin 2022 VMware SD-WAN™ Orchestrator version R421-20211216-GA VMware SD-WAN™ Gateway Version R421-20210407-GA VMware SD-WAN™ Edge Version R421-20210624-GA-57011-60130 Vérifiez régulièrement les ajouts et mises à jour à ces notes de mise à jour.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

• Utilisation recommandée
• Compatibilité
• Remarques importantes
• Historique des révisions
• Problèmes résolus
• Problèmes connus

Utilisation recommandée

Cette version est recommandée pour tous les clients qui exigent une disponibilité préalable des fonctionnalités dans la version 4.2.0, ainsi que ceux concernés par les problèmes répertoriés ci-dessous qui ont été résolus à partir de la version 4.2.0.

Compatibilité

Les instances d'Orchestrator, de Gateway et des dispositifs Edge du Hub version 4.2.1 prennent en charge toutes les versions précédentes du dispositif VMware SD-WAN Edge supérieures ou égales à la version 3.0.0. 
Remarque : cela signifie que les versions antérieures à 3.0.0 ne sont pas prises en charge.

Les combinaisons d'interopérabilité suivantes ont été explicitement testées :

Orchestrator	Gateway	Dispositif Edge
		Hub	Site distant/Spoke
4.2.0	4.2.0	4.2.0	4.2.1
4.2.0	4.2.0	4.2.1	4.2.1
4.2.1	3.4.2	3.4.2	3.4.2
4.2.1	4.2.1	3.4.2	3.4.2
4.2.1	4.2.1	4.2.1	3.4.2
4.2.1	4.2.1	3.4.2	4.2.1
4.2.1	4.2.1	3.4.5	3.4.5
4.2.1	4.2.1	4.2.1	3.4.3, 3.4.4, 3.4.5
4.2.1	4.2.1	3.4.3, 3.4.4, 3.4.5	4.2.1
4.2.1	3.3.2 P3	3.3.2 P3	3.3.2 P3
4.2.1	4.2.1	3.3.2 P3	3.3.2 P3
4.2.1	4.2.1	4.2.1	3.3.2 P2, 3.3.2 P3
4.2.1	4.2.1	3.3.2 P2	4.2.1
4.2.1	3.2.2	3.2.2	3.2.2
4.2.1	4.2.1	3.2.2	3.2.2
4.2.1	4.2.1	4.2.1	3.2.2
4.2.1	4.2.1	3.2.2	4.2.1
4.2.1	4.0.0	4.0.0	4.0.0
4.2.1	4.0.0	4.0.1	4.2.1
4.2.1	4.2.1	4.0.0	4.0.1

Avertissement : Les versions 4.0.x et 4.2.x de VMware SD-WAN ne seront bientôt plus prises en charge. 

• La version 4.0.x atteindra 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 atteindra 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 atteindra la fin du support général (EOGS) le 30 juin 2023 et la fin de l'assistance technique (EOTG) le 30 septembre 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)

Remarque : 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. Une fois que tous les dispositifs Edge exécutent une version 4.x, le client peut choisir entre AES-256-GCM et AES-256-CBC.

Remarques importantes

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 et ultérieures, 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 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 peuvent prendre plus de temps que la normale (de 3 à 5 minutes) sur les modèles de dispositif Edge 3x00 (c'est-à-dire, 3400, 3800 et 3810). Cela est dû à une mise à niveau du microprogramme qui résout le problème 53676. Si un dispositif Edge 3400 ou 3800 avait mis à niveau précédemment son microprogramme lorsqu'il était sous version 3.4.5 ou 4.0.2, il aurait été mis à niveau comme prévu. Pour plus d'informations, consultez le problème résolu 53676.

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 la liaison ne s'active pas même après un redémarrage.

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

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

Historique de révision du document

9 avril 2021. Première édition.

13 avril 2021. Deuxième édition.

• Ajout du problème résolu 53676 à la section Problèmes de dispositifs Edge/passerelles Gateway résolus.  Ce problème a été omis par erreur dans les notes de mise à jour initiales.
• Ajout d'une section Remarques importantes qui traite de la durée de mise à niveau prolongée qu'un dispositif Edge 3x00 devrait rencontrer si son microprogramme devait être mis à niveau dans le cadre du correctif pour 53676.

21 avril 2021. Troisième édition.

• Ajout d'une nouvelle build d'Orchestrator : R421-20210415-GA comme build la plus récente.  Ajout d'une nouvelle section pour R421-20210415-GA à la section Problèmes d'Orchestrator résolus.
• Ajout d'un ticket #61312 à la section Problèmes résolus de R421-20210415-GA d'Orchestrator.

7 mai 2021. Quatrième édition.

• Révision du tableau Compatibilité (Compatibility) pour inclure deux nouvelles combinaisons testées :
  • Orchestrator et Gateway sur la version 4.2.0 sont testés comme compatibles avec un Hub Edge utilisant la version 4.2.0 et un Spoke Edge utilisant la version 4.2.1.
  • Orchestrator et Gateway sur la version 4.2.0 sont testés comme compatibles avec un Hub Edge utilisant la version 4.2.1 et un Spoke Edge utilisant la version 4.2.1.
• Ajout des problèmes résolus 55949 et 56149 à la section Problèmes de dispositifs Edge/passerelles résolus. Ces tickets auraient dû être inclus dans les notes de mise à jour d'origine de GA.

15 juin 2021. Cinquième édition.

• Modification du problème d'Edge/de Gateway résolu 56876 pour expliquer un second scénario que le correctif de ce problème résout. Ce problème concerne également la gestion de la mémoire et provoque une alerte de noyau et un redémarrage du dispositif Edge.
• Ajout du problème d'Edge/de Gateway résolu 54001, qui a été omis par erreur dans les éditions précédentes.

5 août 2021. Sixième édition.

• Ajout de six problèmes connus à la section Problèmes ouverts dans Edge/Gateway : #60006, #60225, #61361, #62552, #63359 et #67790.

11 août 2021. Septième édition.

• Ajout d'une nouvelle version Edge R421-20210624-GA-57011-60130 et déplacement des tickets existants 57011 et 60130 vers la nouvelle section créée pour cette build du dispositif Edge.

16 septembre 2021. Huitième édition. 

• Ajout à Remarques importantes Remarque : Modification du délimiteur de configuration du filtre BGPv4 pour l'ajout du préfixe AS-PATH.

21 décembre 2021. Neuvième édition.

• Ajout d'une nouvelle build d'Orchestrator, R421-20211216-GA, à la section Problèmes d'Orchestrator résolus. Cette build d'Orchestrator corrige la CVE-2021-44228 (vulnérabilité Apache Log4j) en effectuant la mise à jour vers Log4j version 2.16.0. Pour plus d'informations sur la vulnérabilité Apache Log4j, consultez l'avis de sécurité VMware VMSA-2021-0028.5.
• Ajout à Remarques importantes Remarque : 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. Cette note couvre un problème qui peut être rencontré lors de la configuration d'un débit forcé sur certains ports Ethernet des modèles d'Edge répertoriés.

24 mars 2022, dixième édition

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

7 juin 2022, onzième édition

• Ajout du problème résolu n° 54493 à la section Problèmes résolus d'Edge/de Gateway. Ce problème a été omis par erreur de l'édition initiale des Notes de mise à jour de la version 4.2.1.

Problèmes résolus

Les problèmes résolus sont classés comme suit :

• Problèmes de dispositifs Edge résolus
• Problèmes de dispositifs Edge/passerelles Gateway résolus
• Problèmes d'Orchestrator résolus

Problèmes de dispositifs Edge résolus

Résolu dans la version R421-20210624-GA-57011-60130

Les problèmes ci-dessous ont été résolus depuis Edge version R421-20210407-GA.

• Problème résolu 57011 : Pour un site configuré avec une topologie haute disponibilité, chaque fois que des segments sont ajoutés, puis supprimés sur ce site, l'un des dispositifs Edge HA peut subir une panne du service de plan de données et, si celle-ci a lieu sur le dispositif Edge actif, le site subit également un basculement HA.

  Lorsque des segments sont ajoutés, puis supprimés d'un site HA, cela risque de générer des segments périmés (c'est-à-dire que les segments supprimés peuvent toujours s'afficher sur l'un des dispositifs Edge de la paire HA). En raison de cette non-correspondance des informations de segments entre les dispositifs Edge HA, tout événement destiné au segment obsolète peut être envoyé à l'autre dispositif Edge, ce qui entraîne une panne du service de plan de données, un basculement HA si la panne de service a lieu sur le service Edge actif et la génération d'un vidage de mémoire qui se trouvera sur un bundle de diagnostics effectué après le basculement. Il n'existe aucune solution à ce problème.

• Problème résolu 60130 : Un site peut subir des périodes intermittentes de perte élevée de paquets et de problèmes de connectivité.

  Cela provient du fait que l'API vérifie la résolution ARP en indiquant au dispositif Edge une résolution ARP réussie d'un périphérique tout en transmettant une adresse MAC de 00:00:00:00.  Cette adresse est conservée dans le cache ARP et tous les paquets destinés au périphérique sur lequel l'adresse MAC est répertoriée comme étant zéro sont abandonnés. Dans ce problème, de nombreuses instances d'ARP réussies sans adresse MAC sont transmises, ce qui entraîne une perte élevée de paquets et des problèmes de connectivité.

  Ce correctif corrige les problèmes liés à la valeur mise en cache des adresses MAC dans un flux (la cause la plus courante du problème). Toutefois, ce correctif ne résout pas un scénario plus rare dans lequel ARP se met lui-même en cache, puis renvoie une adresse MAC nulle. Ce problème sera résolu dans la version 62552. À part une image Edge avec le correctif, il n'existe aucune solution à ce problème.

Problèmes de dispositifs Edge/passerelles Gateway résolus

Résolus dans la version R421-20210407-GA

Les problèmes ci-dessous ont été résolus depuis la version R420-20201218-GA du dispositif Edge et la version R420-20210208-GA-53243-54800 de la passerelle.

• Problème résolu 51025 : En cas d'instabilité d'une liaison WAN (passage rapide de l'état actif à inactif) sur un dispositif VMware SD-WAN Edge, il se peut que l'entrée de la table de routage de la passerelle par défaut de l'interface routée soit supprimée et non réappliquée.

  Lorsqu'un dispositif Edge se trouve face à ce problème, la liaison devient instable et l'entrée de routage de la passerelle par défaut est supprimée pour l'interface utilisant cette liaison, ce qui donne lieu à une table de routage vide pour l'interface. Toutefois, s'il reste une table de routage vide, le suivi de connexion Linux (conntrack) sera acheminé vers la table suivante par défaut et tous les paquets sortiront donc via la mauvaise interface routée.

• Problème résolu 52102 : Pour une entreprise utilisant une topologie de Hub/Spoke, les flux existants sont abandonnés sur un dispositif VMware SD-WAN Spoke Edge lors de la récupération à partir d'un basculement du dispositif Edge de Hub pour un tuple donné.

  La séquence d'événements génère ce problème lorsqu'un dispositif Edge de Hub principal récupère à partir du basculement :
  1. Lorsque le dispositif Edge de Hub principal tombe en panne, la route est supprimée de la base d'informations de transfert (FIB) pour ce dispositif Edge de Hub principal, tout en conservant les routes dans la base d'informations de routage (RIB).
  2. Les flux existants basculent désormais vers le dispositif Edge de Hub secondaire.
  3. Lorsque le Hub principal est réactivé, un tunnel est immédiatement établi entre le Hub principal du dispositif Spoke Edge.
  4. Les routes de la RIB précédemment apprises du Hub principal via la passerelle sont analysées et installées dans la FIB pointant vers ce Hub principal.
  5. Le trafic rebascule vers le Hub principal, tandis que celui-ci n'a pas appris les routes de son BGP Neighbor.
  6. Cela entraîne une correspondance de la recherche sur la route par défaut et le trafic de retour est marqué par un indicateur de backhaul.
  7. Le dispositif Spoke Edge n'attend pas de trafic de retour avec un indicateur de backhaul défini et cela entraîne l'abandon du trafic. 

  Sans ce correctif, la solution consiste à accéder au dispositif Edge du Hub et à exécuter le diagnostic à distance « Vider les flux » (Flush Flows) pour le tuple donné et le trafic sera rétabli.

• Problème résolu 53415 : Sur un réseau d'entreprise client sur lequel Edge Network Intelligence (ENI) est activé, si le Wi-Fi est activé sur le dispositif VMware SD-WAN Edge de l'entreprise, il se peut que la page ENI affiche une adresse MAC erronée pour le point d'accès Wi-Fi et l'adresse IP du point d'accès sera la suivante : 160.254.3.1.

  Ce problème est dû à une mauvaise configuration de l'adresse MAC du point d'accès Wi-Fi définie sur une valeur appelée « selfMacAddress » et au fait que l'adresse IP du point d'accès est toujours configurée pour 160.254.3.1 sur la page ENI. Le correctif définira l'adresse MAC à partir de l'interface Wi-Fi wlan0 et de l'adresse IP de l'interface d'analyse.

• Problème résolu 53477 : Lorsque les dispositifs VMware SD-WAN Edge configurés dans une topologie à haute disponibilité sont transférés vers un autre profil de configuration, ils rencontrent des redémarrages répétés du service Edge.   

  Pour ce problème, l'un des dispositifs Edge HA est configuré de façon à disposer de plus d'interfaces LAN ou WAN que l'autre dispositif Edge HA (par exemple, un port du WAN est désactivé pour l'un des dispositifs Edge). En cas de transfert de ces derniers vers un autre profil, les dispositifs Edge subissent des redémarrages continus du service Edge.

• Problème résolu 53651 : Sur un site client utilisant une topologie haute disponibilité améliorée, en cas de modification de la configuration d'un paramètre de dispositif VMware SD-WAN Edge nécessitant un redémarrage du service Edge, il se peut que deux basculements HA se produisent l'un après l'autre.

  Pour toute modification de la configuration des paramètres d'un dispositif nécessitant un redémarrage du service Edge, le module HA met à jour de manière erronée le nombre de LAN/WAN sur la passerelle VMware SD-WAN Gateway avant que le service Edge ne redémarre durant le traitement de la configuration. Par conséquent, lorsque le basculement HA initial se produit et le service Active Edge actuel redémarre dans le cadre de sa rétrogradation en mode Veille, la passerelle ne comprend pas que le nouveau dispositif Edge en veille dispose d'un meilleur nombre de LAN/WAN et envoie une commande de basculement au dispositif Edge actif récemment promu, ce qui entraîne un second basculement.

  Remarque : pour obtenir une liste des modifications de configuration de passerelle susceptibles de déclencher un redémarrage du service, consultez l'article de la base de connaissances Modifications de la configuration de passerelle VMware SD-WAN Edge susceptibles de déclencher un redémarrage du service (60247)

• Problème résolu 53676 : Sur la plate-forme VMware SD-WAN Edge 3x00, de très brèves périodes d'instabilité de la tension d'entrée ne dépassant pas 4 millisecondes peuvent entraîner le redémarrage du dispositif Edge.

  Ce problème se produit généralement lors de l'utilisation d'un onduleur (Uninterruptible Power Supply, UPS) qui subit une légère instabilité de la tension de sortie lors du basculement du secteur vers la batterie. Le correctif de ce problème permet de mettre à niveau le microprogramme du dispositif Edge pour tolérer 20 à 30 ms d'instabilité de la tension avant le redémarrage du dispositif Edge.

  Remarque : La mise à niveau du microprogramme du dispositif Edge 3x00 prolonge sa durée de mise à niveau de 3 à 5 minutes si son microprogramme n'était pas précédemment mis à niveau lors de l'utilisation de la version 3.4.5 ou 4.0.2.

  Pour un modèle d'Edge 3x00 sans ce correctif, la seule option du client consiste à utiliser un UPS plus sophistiqué qui peut commuter l'entrée sans instabilité de la tension de sortie. 

• Problème résolu 53789 : Sur les dispositifs Edge virtuels VMware SD-WAN fonctionnant sous ESXi, le champ /var/journal/messages affiche un faux message d'erreur toutes les 30 secondes.

  Ci-après, le faux message d'erreur en question : GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root" et il est toujours connecté à /var/journal/messages, ce qui entraîne un remplissage du champ /var/journal/messages et du champ associé enregistré /velocloud/journal/messages*, provoquant la sortie par rotation et la perte des messages les plus importants lors de la consultation des journaux pour le dispositif Edge concerné.

• Problème résolu 53929 : Sur un site client utilisant une topologie haute disponibilité améliorée, après un basculement HA, les flux « Cloud via une passerelle » (Cloud via Gateway) passent au chemin d'accès « Direct vers le Cloud » (Direct to Cloud).

  Après un basculement HA, si le chemin d'accès à la passerelle VMware SD-WAN Gateway n'est pas actif lorsque le trafic atteint le dispositif VMware SD-WAN Edge, le trafic passe à « Direct vers le cloud » (Direct to cloud) au lieu de « Cloud via une passerelle » (Cloud via Gateway). Cela peut avoir un effet significatif sur les flux qui dépendent des optimisations de chemins multiples dynamiques, telles que le trafic en temps réel (par exemple, vocal et vidéo), car le trafic direct n'utilise pas ces optimisations.

• Problème résolu 54001 : Un dispositif VMware Edge n'est pas en mesure d'envoyer de trafic après le blocage d'une file d'attente de transmission (Tx) sur les interfaces SFP.

  Dans de rares cas où le dispositif Edge envoie un paquet de taille non valide (inférieure à 17 octets ou supérieure à 1 526 octets) au DPDK, la file d'attente de transmission se bloque et le trafic supplémentaire n'est pas transféré par le dispositif Edge. Le redémarrage du dispositif Edge corrige temporairement le problème, mais celui-ci peut se reproduire lorsqu'un paquet de taille non valide est envoyé du service Edge au DPDK. Seule la mise à niveau vers un niveau comportant le correctif évite ce problème.

• Problème résolu 54493 : Un administrateur d'opérateur ou de partenaire peut observer un nombre croissant de handoff queue drops pour le trafic Edge sur une instance de VMware SD-WAN Gateway. 

  Pour ce problème, la passerelle ne présente aucun problème d'utilisation de CPU ni d'abandon DPDK. Ce problème est déclenché par un événement de plan de contrôle (par exemple, recalcul des routes). La passerelle commence alors à abandonner des paquets du dispositif Edge lors du transfert vers différents threads du pipeline de la passerelle. Ce problème est dû à une taille de file d'attente insuffisante pour la mise en mémoire tampon des paquets.

• Problème résolu 54694 : Lorsqu'un client a recours à la scrutation de protocole SNMP, la surveillance du protocole SNMP fournit des mesures inexactes du trafic sortant

  L'appel du protocole SNMP pour IF-MIB::ifHCOutOctets fournit des paquets TX plutôt que des octets TX, entraînant une erreur au niveau du nombre d'octets sortants, ce qui a un effet sur la capacité du client à surveiller son entreprise. Ce problème découle de la différence entre le nombre d'octets Tx et le nombre de paquets Tx de surveillance du processus snmpagent.

• Problème résolu 55949 : Dans certains scénarios, un tunnel de destination non-SD-WAN (NSD) via une passerelle tombe en panne et ne récupère pas pendant une période donnée.

  Dans le cas où une passerelle VMware SD-WAN Gateway déclenche un renouvellement de clés IKE avec toute autre destination NSD et que la tentative de renouvellement de clés échoue en raison d'un problème de mise en réseau en cours de négociation, de nouvelles tentatives sont effectuées. En cas de rétablissement d'une liaison, il est possible que l'événement Détection des homologues inactifs (DPD, Dead Peer Detection) supprime une association de sécurité (SA) de phase 1 récemment créée. Cela entraîne la suppression de la SA IPsec avec certains homologues, notamment avec Zscaler. Lorsqu'un homologue supprime la SA IPsec, la passerelle n'est pas en mesure de la détecter et un tunnel est inactif jusqu'au prochain délai de renouvellement.  Sans le correctif, la seule façon de forcer ce renouvellement de clés consiste à refuser le tunnel en désactivant et en réactivant la NSD concernée via VMware SD-WAN Orchestrator.

• Problème résolu 56149 : Après l'activation du Calcul du coût dynamique (Dynamic Cost Calculation, DCC) sur une entreprise de client qui utilise BGP, un dispositif VMware SD-WAN Edge peut indiquer une valeur de préférence de route incorrecte pour les valeurs corrigées automatiquement en cas de bagotement de la route BGP pour la route de superposition.

  L'incidence sur le client est un routage asymétrique en raison de la préférence de route distante incorrecte, ce qui entraîne une latence plus élevée et de faibles performances sur toutes les applications du client. Après l'activation du DCC, vous devez mettre à jour la nouvelle valeur de préférence de la base d'informations de routage (RIB) sur la route. Vous devez alors annoncer de nouveau celle-ci à la passerelle VMware SD-WAN Gateway avec la nouvelle valeur de préférence RIB qui est ensuite communiquée à tous les dispositifs Edge. Ce problème s'explique par le fait que lorsque la route est corrigée automatiquement, cette préférence de RIB n'est pas mise à jour dans la table FIB du dispositif Edge de l'homologue. L'ancienne valeur pré-DCC est alors conservée. 

• Problème résolu 56346 : Il se peut que le client soit confronté à des handoff queue drops lorsqu'il va dans Surveillance VMware SD-WAN Edge (VMware SD-WAN Edge's Monitor) > Page système (System page).

  Les mises à jour d'événements de routage VCRP (VeloCloud Route Protocol) entraînent des handoff queue drops dans le thread de données VCMP (VeloCloud Management Plane).  Cela est dû au fait que lors de la réception d'une mise à jour de route, toutes les routes dans le segment respectif sont invalidées. Cela donne lieu à de nouvelles recherches de route dans le chemin de données. Une fonction particulière sollicitée dans le cadre de la recherche de routes réalise une lourde opération d'énumération des événements de hachage, entraînant une augmentation de 40 % de l'utilisation du thread de données VCMP.  Dans le cas précis dans lequel ce problème a été décelé sur site, le nombre de handoff queue drops n'était pas suffisant pour avoir un effet sur les performances réseau.

• Problème résolu 56483 : Les valeurs de perte de paquets, gigue et latence ne s'affichent pas dans la surveillance en direct de la liaison WAN sur une instance de VMware SD-WAN Orchestrator dans l'écran Surveiller (Monitor) > Transport.

  Un utilisateur ne peut pas obtenir de données en temps réel pour une perte de paquets, une gigue ou une latence pour une liaison WAN spécifique sous Surveiller (Monitor) > Transport, avec l'affichage du graphique sous la forme d'une ligne plate. En outre, lorsque vous examinez l'écran Surveiller (Monitor) > Dispositif Edge (Edge) > Présentation (Overview), toutes les valeurs de perte, gigue et latence sont exprimées par « 0 ». Les statistiques historiques s'affichent correctement dans Surveiller (Monitor) > Transport. Ce problème n'affecte que sur les statistiques du « Mode direct » (Live Mode). 

• Problème résolu 58535 : Dans le cas où un client configure un pare-feu avec état et s'il a configuré une liste bloquée dans Protection du réseau et de propagation, la liste bloquée se définit automatiquement sur les paramètres les plus agressifs pour les nouvelles connexions et le pare-feu avec état bloque toute nouvelle connexion.

  Ce problème a un effet critique pour les clients qui utilisent un pare-feu avec état, car il rend la fonctionnalité Liste bloquée inutilisable. Une fois la fonctionnalité Liste bloquée activée, les événements de pare-feu sont remplis à l'aide des journaux : « FLOOD_ATTACK_DETECTED » et « Source de liste bloquée : xxx.xxx.x.x a dépassé la limite CPS : 0 par source ».  Avec l'adresse IP de gestion du dispositif Edge comme adresse IP et CPS = connexions par seconde. La nouvelle limite de seuil de connexion est définie sur 0 %, ce qui signifie en réalité que toutes les tentatives de connexion seront bloquées par la liste bloquée.  La valeur par défaut du nouveau seuil de connexion est de 25 %.

• Problème résolu 56876 : Un dispositif VMware SD-WAN Edge peut rencontrer un problème lié à la gestion de la mémoire et déclencher une alerte de noyau, ce qui provoque un redémarrage du dispositif Edge.

  Ce problème résolu inclut des correctifs pour deux scénarios différents impliquant la gestion de la mémoire sur un dispositif Edge, ce qui déclenche une panique du noyau :

  1. Dans le premier scénario, lorsqu'un dispositif Edge utilise un système de site distant à site distant dynamique, les tunnels dynamiques sont créés et une petite quantité de mémoire est réservée au stockage des compteurs par homologue. Lors de la désinstallation du tunnel dynamique, cette mémoire n'est pas nettoyée afin d'optimiser le délai de mise en place à la prochaine connexion de ce même homologue. Sur un dispositif Edge de petite taille (par exemple, Edge 500, 510, 520, 610) qui se connecte à un grand nombre de destinations différentes dans le temps, cela peut finir par épuiser la mémoire disponible et déclencher une alerte de noyau et un redémarrage du dispositif Edge.  Sans ce correctif, un utilisateur doit redémarrer de manière proactive le service du dispositif Edge si l'utilisation de la mémoire est supérieure à 90 % des statistiques de santé lorsqu'il consulte l'écran Surveiller (Monitor) > Système (System) d'un dispositif Edge sur VMware SD-WAN Orchestrator.
  2. Lors de la résolution de la fuite de mémoire provoquée par le système de site distant à site distant dynamique, il a été observé que malloc_trim (processus qui efface la mémoire fragmentée) n'était pas correctement appelé et que ce processus était également modifié pour ce correctif. Si vous n'appelez pas malloc_trim correctement, cela peut provoquer un autre problème et avoir une incidence sur tout dispositif Edge (pas uniquement ceux de taille inférieure) et n'exige pas que le dispositif Edge utilise le système de site distant à site distant dynamique, ni que l'option Surveiller (Monitor) > Système (System) affiche une utilisation de la mémoire dépassant 90 %. Ce scénario est beaucoup plus susceptible de se produire si le dispositif Edge présente un nombre élevé de flux.
• Problème résolu 56931 : Un site client ayant configuré une destination non-SD-WAN (NSD) via le dispositif Edge peut afficher des statistiques de santé incorrectes relatives au dispositif Edge sur l'interface utilisateur de VMware SD-WAN Orchestrator.

  Lorsqu'une NSD est configurée à partir du dispositif Edge, le service SD-WAN envoie des statistiques de santé du dispositif Edge à Orchestrator avec 0 comme heure de début pour la première fois après le redémarrage. Orchestrator affiche alors des données erronées après le redémarrage du dispositif Edge.

• Problème résolu 57063 : Si les heures de début et de fin d'un appel d'API chevauchent précisément l'heure à laquelle un dispositif VMware SD-WAN Edge exporte des données vers VMware SD-WAN Orchestrator, deux comportements sont observés : a) Les appels d'API de mesures des liaisons émis par l'interface utilisateur d'Orchestrator ou les clients SDK observent une valeur supérieure à la normale renvoyée dans la réponse. b) Les appels d'API de la série de liaisons émis à partir de l'interface utilisateur d'Orchestrator ou des clients SDK observent que la dernière valeur de la série chronologique est supérieure à la valeur habituelle.

  Un utilisateur peut observer cette différence lors de l'examen de l'onglet Surveiller (Monitor) > Transport sur l'interface utilisateur d'Orchestrator ou lorsqu'un client SDK invoque les appels d'API getEdgeLinkMetrics, getEdgeLinkSeries, getAggregateLinkMetrics.  Dans les deux cas, les heures réelles observées sont rares en raison des conditions requises notées dans la description des symptômes.

Problèmes d'Orchestrator résolus

Orchestrator version R421-20211216-GA

Orchestrator version R421-20211216-GA a été publié le 20-12-2021. Cette build d'Orchestrator corrige la CVE-2021-44228 (vulnérabilité Apache Log4j) en effectuant la mise à jour vers Log4j version 2.16.0. Pour plus d'informations sur la vulnérabilité Apache Log4j, consultez l'avis de sécurité VMware VMSA-2021-0028.5.

___________________________________________________________________

Résolus dans la version R421-20210415-GA

Les problèmes ci-dessous ont été résolus depuis Orchestrator version R421-20210326-GA.

• Problème 61312 résolu : Une instance de VMware SD-WAN Orchestrator peut rencontrer un problème dans lequel les routes ne sont plus mises à jour et l'utilisation du CPU d'Orchestrator approche 100 %, en particulier après la mise à niveau d'Orchestrator.

  Ce problème se manifeste lorsqu'un dispositif Edge envoie environ au moins 2 000 mises à jour de routes à l'API de routage d'Orchestrator. Dans les scénarios dans lesquels Orchestrator n'est pas en mesure de traiter l'ensemble complet des routes envoyées sur un appel d'API particulier dans les 60 secondes, cela entraîne un délai d'expiration pour cet appel, puis un rejet complet de l'appel d'API. Le dispositif Edge reçoit ce rejet et tente de nouveau de transférer les mêmes 2 000 routes au moins vers Orchestrator, ce qui entraîne le même scénario que celui d'avant créant une boucle qui surcharge les ressources vCPU d'Orchestrator. Lorsque ce problème est présent, il peut empêcher le traitement des mises à jour de routes. 

  Pour résoudre ce problème, deux propriétés système ont été ajoutées :

  edge.learnedRoute.maxRoutePerCall : cette propriété garantit le traitement d'un nombre limité de routes uniquement à partir d'un dispositif Edge. Si la valeur de la propriété est de « 200 », 200 routes sont traitées par demande du dispositif Edge, ce qui garantit l'envoi d'une confirmation au dispositif Edge à temps.

  vco.learnedRoute.simultaneous.maxQueue : cette propriété garantit des demandes de routes mises en file d'attente simultanément pour le nombre configuré de dispositifs Edge uniquement. Si la valeur de la propriété est de « 8 », seuls 8 dispositifs Edge sont autorisés à envoyer des demandes de routes simultanément. Ceux qui dépassent la valeur configurée sont alors rejetés immédiatement avant le traitement des routes.

______________________________________

Résolus dans la version R421-20210326-GA

Les problèmes ci-dessous ont été résolus depuis Orchestrator version R420-20210306-GA.

• Problème 20900 : Si le service de géolocalisation MaxMind est activé et ne peut pas accéder au serveur MaxMind, les nouvelles activations du dispositif VMware SD-WAN Edge ne fonctionneront pas.

  Le dispositif Edge crée une connexion HTTPS sur VMware SD-WAN Orchestrator afin de l'activer. Le délai d'expiration par défaut pour la demande est de 120 secondes et de 60 secondes pour la connexion au proxy. Lors de la tentative de géolocalisation du dispositif Edge (adresse distante IPv4) de la part d'Orchestrator, les chargements attendent la réponse du service MaxMind avant de poursuivre l'activation. Ainsi, après 60 secondes, NGINX s'arrête pour attendre la réponse du service de chargement et ferme la connexion. L'activation échoue donc en raison d'une Erreur 504 : délai d'expiration du NGINX. 

  Avec la nouvelle propriété système service.maxmind.timeout.seconds, l'appel API Maxmind est réalisé avec un délai d'expiration personnalisé. Lorsque le délai expire, l'appel se poursuit avec le workflow d'activation et le dispositif Edge s'active donc correctement.

• Problème résolu 49997 : Si le mode d'analyse VMware Edge Network Intelligence est activé sur une instance de VMware SD-WAN Orchestrator, lors de la création d'un nouvel utilisateur opérateur, cet opérateur ne peut pas se connecter aux sections d'analyse de l'interface utilisateur Orchestrator.

  Les utilisateurs opérateurs créés après activation du mode d'analyse doivent pouvoir accéder à l'interface utilisateur VMware Edge Network Intelligence de toutes les entreprises clientes qui ont activé l'accès, et ce n'est pas le cas avec ce problème.

• Problème résolu 52379 : VMware SD-WAN Orchestrator envoie un e-mail d'alerte « Dispositif Edge inactif » (Edge Down) si VMware SD-WAN Edge récupère dans l'intervalle de temps configuré.

  Il se peut que les administrateurs reçoivent de fausses alertes de dispositif Edge inactif sur leur réseau, même s'ils ont configuré un délai qui prévoit une période d'inactivité du dispositif Edge avant le déclenchement de cette alerte.

• Problème résolu 53525 : Lors de l'utilisation de la nouvelle interface utilisateur sur une instance de VMware SD-WAN Orchestrator et lors de la consultation de la page de présentation du dispositif Edge, la colonne Liaisons n'affiche pas l'état de la liaison (Sauvegarde, Veille, par ex.).

  Ces informations d'état de liaison sont correctement affichées sur l'ancienne interface utilisateur et grâce à ce correctif elles s'afficheront comme prévu sur la nouvelle interface utilisateur.

• Problème résolu 53652 : Lorsqu'une entreprise cliente qui a recours à un mappage d'application personnalisé est mise à niveau de la version 3.x vers la version 4.x, il se peut que le client se rende compte que des noms aléatoires ont été attribués à ses applications personnalisées créées avant la mise à niveau.

  Chaque fois qu'un mappage d'application personnalisé est configuré avec un ID d'application (ID d'app) qui existe déjà dans le cadre du mappage d'application initial par défaut, VMware SD-WAN Orchestrator affichera toujours le nom complet du mappage d'application initial par défaut et remplacera le nom défini par le client. Cela est également vrai lorsque Orchestrator est mis à niveau d'une version antérieure vers une version supérieure et lorsque le mappage d'application initial par défaut de la version supérieure dispose d'un ID d'app qui crée un conflit avec l'ID d'app des applications personnalisées créées dans une version antérieure.  Après la mise à niveau d'Orchestrator, ces applications personnalisées affichent un nom complet erroné qui correspond au nom complet de l'ID d'app du mappage d'application initial par défaut de la version supérieure.

• Problème résolu 53752 : La migration d'une entreprise cliente échoue lorsqu'elle est tentée à partir d'une instance de VMware SD-WAN Orchestrator utilisant la version 3.4.x sur une instance d'Orchestrator utilisant la version 4.2.0.

  La dernière version de l'outil de migration d'entreprise ne prenait pas en charge la version 4.2.x, c'est la raison pour laquelle les migrations échouaient à chaque fois.

• Problème résolu 53857 : Tout déploiement de VMware SD-WAN Orchestrator utilisant une image KVM basée sur la version 4.0.0 échouera.

  Cet échec est dû au fait que la taille de disque virtuel de l'image KVM n'est pas la bonne et les volumes ne se développeront donc pas à la taille requise.  Lors d'un déploiement, les scripts Orchestrator développent automatiquement les volumes Orchestrator afin qu'ils occupent 80 % de la taille maximale des disques sous-jacents (volumes physiques).  Dans ce cas précis, du fait de la taille virtuelle erronée, ce développement ne correspond pas aux exigences de la base de données Orchestrator et le déploiement échoue.  Il est possible de déployer un Orchestrator à l'aide d'une build plus ancienne sans ce correctif, mais les volumes doivent être redimensionnés manuellement.

• Problème résolu 53987 : Sur une instance de VMware SD-WAN Orchestrator, il est impossible de rechercher l'événement Edge « MTU de liaison détectée » (Link MTU Detected) sur l'interface utilisateur d'Orchestrator.

  Ce problème a été observé sur les instances d'Orchestrator utilisant la version 4.0.x et versions supérieures.  Lors d'une recherche d'événements dans l'interface utilisateur d'Orchestrator, sur la page Événements, l'événement « MTU de liaison détectée » (Link MTU Detected) n'est pas disponible dans la liste des événements pour le filtre, ce qui complique l'isolation de cet événement dans le cadre d'un effort de dépannage.

• Problème résolu 54035 : Si le mode d'analyse VMware Edge Network Intelligence est activé, les paquets destinés au syslog daemon, au aruba daemon et au snmtrap daemon sont abandonnés sur le VMware SD-WAN Edge et ces données ne s'afficheront pas dans la visionneuse Edge Network Intelligence.

  Les paquets destinés aux daemons Edge Network Intelligence (syslogd, apt et snmptrapd) sont abandonnés lors du processus du plan de données Edge en raison de l'absence de règles iptable correspondantes. Par conséquent, les statistiques correspondantes n'arriveront pas dans le service principal Edge Network Intelligence.

• Problème résolu 55259 : Lorsqu'un administrateur crée un nouveau dispositif VMware SD-WAN Edge sur l'interface utilisateur de VMware SD-WAN Orchestrator, le champ « Définir l'emplacement » (Set location) n'apparaît pas.

  À cause de ce problème, l'administrateur peut créer le dispositif Edge, mais sans informations d'emplacement et Orchestrator ne peut pas effectuer de géolocalisation automatique pour le dispositif Edge, ni attribuer les bonnes passerelles.  L'administrateur doit effectuer une opération supplémentaire après la création du dispositif Edge, pour pouvoir s'y rendre et remplir les informations d'emplacement du dispositif Edge sur la page présentation de Configurer (Configure) > Dispositif Edge (Edge) > Présentation du dispositif Edge (Edge Overview).

• Problème résolu 55871 : Certains appels API sur l'HTTP REST APIv2 (/sdwan) génèrent des erreurs HTTP 500 sur le serveur.

  Dans certains cas où les données du client ne sont pas exactement conformes au schéma auquel l'API s'attend, l'API génère une erreur HTTP 500 plutôt que de renvoyer des données qui ne correspondent pas au schéma d'API documenté. Ce comportement était dû à une décision de calcul qui a été rectifiée depuis. Les appels à « GET/enterprises », « GET /enterprises/{enterpriseLogicalId}/edges », et « GET /enterprises/{enterpriseLogicalId}/clientDevices » sont connus pour en subir les effets.

• Problème résolu 56763 : Sur une instance de VMware SD-WAN Orchestrator utilisant la version 4.x ou ultérieure avec les rapports activés, si la création d'un rapport échoue pour une raison quelconque, la création de tous les rapports suivants échouera également jusqu'au redémarrage du service principal d'Orchestrator.

  Ce problème a une incidence majeure sur une instance d'Orchestrator concernée, car tous les clients utilisant Orchestrator se trouveront dans l'impossibilité de obtenir des rapports tant que le service principal d'Orchestrator n'aura pas été redémarré. Ce problème est dû à un échec de rapport unique qui place le service de rapports dans un état incorrect à partir duquel il ne peut se remettre sans redémarrage du service principal sur Orchestrator.  Cela est dû au fait que la génération du nouveau rapport ne se fait pas de façon indépendante par rapport à la génération du rapport précédent.  Le correctif permet de garantir que le service de génération des rapports continue de générer de nouveaux rapports indépendamment d'un quelconque échec de génération de rapport.

• Problème résolu 56824 : Sur une instance de VMware SD-WAN Orchestrator utilisant la version 4.2.x, la transmission d'alertes aux destinataires Webhook échoue lorsque l'URL du destinataire comprend un numéro de port explicite.

  Les utilisateurs qui avaient précédemment configuré des URL de destinataires Webhook qui contenaient des numéros de port explicites se rendront compte que la transmission d'alertes à ces destinataires échoue indéfiniment. Sans le correctif prévu dans cette build, les administrateurs sont obligés de configurer un proxy inverse pour transmettre les demandes au destinataire Webhook d'origine et mettre à jour l'URL du destinataire Webhook pour qu'elle transmette les demandes au proxy inverse.

• Problème résolu 56896 : Il se peut que l'utilisateur soit confronté à des échecs d'API et à des délais d'expiration de passerelle.

  Ce problème est dû au fait que le stockage sur disque d'une instance de VMware SD-WAN Orchestrator est plein à cause d'une accumulation de fichiers. Cette accumulation se produit parce qu'il existe un moyen de désactiver le traitement des statistiques de flux pour un dispositif VMware SD-WAN Edge ou une liste de dispositifs Edge ressemblant à une fonctionnalité de liste bloquée. Bien que le traitement du flux soit ignoré pour ces dispositifs Edge, le problème, c'est que les fichiers restent sur le disque Orchestrator sans être supprimés. Dans l'instance dans laquelle ce problème a été décelé, une surveillance suffisante avait déjà été mise en place pour détecter ce problème et éviter tout problème d'expérience utilisateur, mais sur un Orchestrator avec moins de surveillance, cela pourrait avoir un effet sur le trafic client. Sans ce correctif, l'opérateur Orchestrator devra supprimer manuellement les fichiers sur le stockage sur disque Orchestrator avec un horodatage de plus de 24 heures.

• Problème résolu 56909 : Sur une instance de VMware SD-WAN Orchestrator utilisant la version 4.x, la génération de rapports est susceptible d'échouer lorsqu'un lien de sauvegarde est inclus.

  Lorsqu'un lien ne dispose pas de données statistiques de lien, la génération du rapport génère une erreur.  Un lien configuré sur sauvegarde ne générera aucune statistique de lien s'il reste strictement en mode sauvegarde durant la période sélectionnée pour le rapport. Sans ce correctif, la seule façon de générer un rapport consiste à désélectionner le lien de sauvegarde lors de la génération d'un rapport afin que le lien dispose de données statistiques pour son enregistrement.

• Problème résolu 57087 : Lorsque l'utilisateur tente de changer de profil VMware SD-WAN Edge à partir de l'écran Configurer (Configure) > Edge, l'utilisateur se heurte à une erreur de validation qui inclut une fenêtre de notification contenant un message d'erreur générique au lieu de la raison réelle.

  L'erreur générique affichée indique « Erreur lors du traitement de l'élément. Veuillez réessayer ». Pour connaître la raison réelle de l'erreur de validation, l'utilisateur a dû se reporter à la console de débogage d'un navigateur Web. Après le correctif, l'erreur de validation/la raison appropriée de l'échec s'affiche.

• Problème résolu 58627 : Les utilisateurs configurés pour recevoir des alertes peuvent recevoir une alerte de liaison active alors qu'en réalité la liaison demeure inactive.

  Parfois, après qu'une liaison soit déclarée « Inactive » (Down), les statistiques de cette liaison qui ont été générées avant que la liaison soit inactive peuvent ne pas être envoyées à l'instance de VMware SD-WAN Orchestrator pendant jusqu'à une minute après l'événement.  Une fois qu'Orchestrator reçoit ces statistiques de liaison en retard, il considère à tort que la liaison est en cours de sauvegarde et déclenche donc une alerte de liaison active si les paramètres d'alerte sont agressifs (0 minute de délai, par ex.).  Le correctif garantit qu'Orchestrator n'interprète pas les statistiques de liaison différée comme une indication que la liaison est désormais active.

• Problème résolu 59094 : Lorsqu'un opérateur tente de mettre à niveau une instance de VMware SD-WAN Orchestrator, le script de mise à jour ne fournit pas de message d'avertissement adéquat à propos des conditions requises pour la mise à jour du schéma.

  Si l'opérateur rate l'étape d'application des modifications de schéma sur des tables de plus grande taille, il se peut qu'une erreur soit générée au niveau des services Orchestrator.  De plus, il n'y a aucun moyen simple de savoir quelles sont les modifications manquantes. Ce correctif résout ce problème quand, lors du redémarrage du service principal, il génère à nouveau toutes les modifications de schéma manquantes nécessaires sur une table de grande taille.

• Problème résolu 59967 : Après la mise à niveau d'une instance de VMware SD-WAN Orchestrator vers la version 4.2.x ou version supérieure, lorsqu'un utilisateur opérateur tente d'accéder aux pages de stratégie Configurer (Configure) > Business Policy ou Configurer (Configure) > Pare-feu (Firewall), la page ne se charge pas et un message d'erreur s'affiche.

  Message d'erreur :« Une erreur inattendue s'est produite ». Cela a un effet sur les utilisateurs opérateurs, et non pas sur les administrateurs clients ou partenaires. Les pages ne se chargent pas en raison de l'absence d'un privilège READ: OBJECT_GROUP pour les opérateurs, ce qui signifie qu'Orchestrator ne reconnaît pas l'opérateur comme ayant les privilèges nécessaires pour accéder aux pages Business policy et Pare-feu.

Problèmes connus

Problèmes ouverts dans la version 4.2.1

Les problèmes connus sont classés comme suit :

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

Problèmes connus liés à Edge/Gateway

• Problème 14655 :

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

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

• Problème 25504 :

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

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

• Problème 25595 :

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

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

• Problème 25742 :

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

• Problème 25758 :

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

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

• Problème 25855 :

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

  Solution : Aucune solution disponible.

• Problème 25921 :

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

• Problème 25997 :

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

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

• Problème 26421 :

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

• Problème 28175 :

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

• Problème 31210 :

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

• Problème 32731 :

  Les routes conditionnelles par défaut annoncées via OSPF peuvent ne pas être correctement retirées lorsque la route est désactivée. La réactivation et la désactivation de la route garantit la réussite de sa rétractation. 

• Problème 32960 :

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

• Problème 32981 :

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

• Problème 34254 :

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

• Problème 35778 :

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

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

• Problème 35807 :

  Une interface routée DPDK sera désactivée complètement si l'interface est désactivée et réactivée depuis VMware SD-WAN Orchestrator. 

• Problème 36923 :

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

• Problème 38682 :

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

• Problème 38767 :

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

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

• Problème 39134 :

  Les statistiques de santé du système Pourcentage du CPU (CPU Percentage) ne peuvent pas être signalées correctement sur Surveiller (Monitor) > Dispositif Edge (Edge) > Système (System) pour le dispositif VMware SD-WAN Edge et sur Surveiller (Monitor) > Passerelles (Gateways) pour la passerelle VMware SD-WAN Gateway.

  Solution : Les utilisateurs doivent utiliser des handoff queue drops pour surveiller la capacité du dispositif Edge sans pourcentage du CPU.

• Problème 39374 :

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

• Problème 39608 :

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

• Problème 39624 :

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

• Problème 39659 :

  Sur un site configuré pour la haute disponibilité améliorée, avec une liaison WAN sur chaque dispositif VMware SD-WAN Edge, lorsque le dispositif Edge en veille n'a que le protocole PPPoE connecté et que le dispositif actif n'est connecté qu'à un réseau non PPPoE, un état split-brain (actif/actif) peut être possible si le câble HA échoue.

• Problème 39753 :

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

• Problème 40096 :

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

  Solution : Déconnectez le module SFP, puis reconnectez-le au port.

• Problème 40421 :

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

• Problème 42278 :

  Pour un type spécifique de mauvaise configuration de l'homologue, la passerelle VMware SD-WAN Gateway peut envoyer en continu des messages d'initialisation IKE à un homologue non-SD-WAN. Ce problème n'interrompt pas le trafic utilisateur vers la passerelle. Cependant, les journaux de la passerelle se rempliront avec des erreurs IKE et cela peut masquer des entrées de journal utiles.

• Problème 42388 :

  Sur un dispositif VMware SD-WAN Edge 540, un port SFP n'est pas détecté après la désactivation et la réactivation de l'interface à partir de VMware SD-WAN Orchestrator.

• Problème 42488 :

  Sur un dispositif VMware SD-WAN Edge sur lequel VRRP est activé pour un port commuté ou routé, les routes connectées au LAN sont annoncées si le câble est déconnecté du port et que le service Edge est redémarré.

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

• Problème 42872 :

  L'activation de l'isolation de profils sur un profil Hub dans lequel un cluster de Hubs est associé ne révoque pas les routes de Hubs de la base d'informations de routage (RIB).

• Problème 43373 :

  Lorsque la même route BGP est apprise à partir de plusieurs dispositifs VMware SD-WAN Edge, si cette route est déplacée de sortie préférée à sortie éligible dans Contrôle de flux de superposition (Overlay Flow Control), le dispositif Edge n'est pas supprimé de la liste d'annonces et continue d'être annoncé.

  Solution : Activez le calcul du coût distribué sur VMware SD-WAN Orchestrator.

• Problème 44526 : Cas d'une entreprise dans laquelle deux sites différents déploient leurs dispositifs VMware SD-WAN Edge comme Hubs tout en utilisant également une topologie haute disponibilité, chaque site utilisant l'autre site de Hub comme Hub dans son profil.  Si l'un des sites de Hub déclenche un basculement HA, le rétablissement des tunnels entre eux peut prendre jusqu'à 30 minutes pour les deux dispositifs Edge de Hub. 

  Lors d'un basculement HA, les deux dispositifs Edge de Hub tentent d'initier un tunnel entre eux au même moment et aucun des deux ne répond à l'homologue. L'échange de paquets entre les deux Hubs a lieu, mais IKE ne réussit jamais. Cela provoque un blocage dont la résolution automatique peut prendre, selon les observations, jusqu'à 30 minutes. Le problème est intermittent et ne se produit pas après chaque basculement HA. 

  Solution : Pour éviter ce problème, le client doit configurer uniquement l'un des deux sites de Hub HA pour utiliser l'autre site de Hub comme Hub pour lui-même.  Par exemple, lorsqu'il existe deux sites de Hub HA, Hub1 et Hub2, Hub1 peut avoir Hub2 comme Hub pour lui-même dans son profil, mais Hub2 ne doit pas utiliser Hub1 comme Hub dans son profil.

• Problème 44832 :

  Le trafic issu de destinations non-SD-WAN via un dispositif Edge vers d'autres destinations non-SD-WAN via un dispositif Edge (« hairpinning » ou « bouclage NAT ») est abandonné sur le dispositif VMware SD-WAN Edge.

• Problème 44995 :

  Les routes OSPF ne sont pas révoquées des passerelles VMware SD-WAN Gateway et des dispositifs VMware SD-WAN Spoke Edge lorsque les routes sont retirées du cluster de Hubs.

• Problème 45189 :

  Lors de la configuration d'un NAT source côté LAN, le trafic provenant d'un dispositif VMware SD-WAN Edge vers un Hub Edge est autorisé même sans la configuration de route statique pour le sous-réseau NAT.

• Problème 45302 :

  Dans un cluster de Hubs de VMware SD-WAN, si un Hub perd la connectivité pendant plus de 5 minutes vers toutes les passerelles VMware SD-WAN Gateway communes entre lui-même et ses dispositifs Spoke Edge associés, les Spokes peuvent dans de rares cas ne pas pouvoir conserver les routes de Hub après 5 minutes. Le problème se résout automatiquement lorsque le Hub reprend contact avec les passerelles.

• Problème 46053 :

  La préférence BGP n'est pas corrigée automatiquement pour les routes de superposition lorsque son voisin devient un voisin de liaison montante.

  Solution : Un redémarrage du service Edge corrigera ce problème.

• Problème 46137 :

  Un dispositif VMware SD-WAN Edge exécutant un logiciel 3.4.x n'établit pas de tunnel avec un chiffrement AES-GCM même si le dispositif Edge est configuré pour GCM.

• Problème 46216 :

  Sur des destinations non-SD-WAN via une passerelle ou un dispositif Edge sur lequel l'homologue est une instance d'AWS, lorsque l'homologue initie un renouvellement de clés de phase 2, l'IKE de phase 1 est également supprimé et impose un renouvellement de clés.  Cela signifie que le tunnel est détruit et recréé, ce qui entraîne une perte de paquets lors de la reconstruction du tunnel.

  Solution : Pour éviter la destruction du tunnel, configurez les destinations non-SD-WAN via une passerelle/dispositif Edge ou un temporisateur de renouvellement de clés IPsec CSS défini à moins de 60 minutes.  Cela empêche AWS de lancer le renouvellement de clés.

• Problème 46391 :

  Pour un dispositif VMware SD-WAN Edge 3800, les interfaces SFP1 et SFP2 présentent chacune des problèmes avec des SFP multivoie (c'est-à-dire 1/10G) et ne doivent pas être utilisées dans ces ports.

  Solution : Utilisez le mode SFP à taux unique conformément à l'article de la base de connaissances Liste de modules SFP pris en charge par VMware SD-WAN (79270).  Les SFP à taux multiples peuvent être utilisés avec SFP3 et SFP4.

• Problème 46918 :

  Un dispositif VMware SD-WAN Spoke Edge utilisant la version 3.4.2 ne met pas correctement à jour l'ID de réseau d'une propriété de nœud de Hub de cluster.

• Problème 47084 :

  Un dispositif VMware SD-WAN Hub Edge ne peut pas établir plus de 750 voisins PIM (Protocol-Independent Multicast) lorsque des dispositifs Spoke Edge 4000 y sont attachés.

• Problème 47244 :

  Sur un dispositif VMware SD-WAN Edge 6x0 actif sur lequel DPDK est activé, et doté de certains SFP en cuivre, le dispositif Edge affiche la liaison comme ACTIVE (UP) même lorsqu'aucun câble n'est inséré sur l'interface utilisateur de VMware SD-WAN Orchestrator.

  Solution : Le branchement et le débranchement d'un câble suppriment l'état False.

• Problème 47355 :

  Lorsque la même route est apprise via une sous-couche BGP locale, Hub BGP et/ou statiquement configurée sur la passerelle partenaire, l'ordre de tri des routes est incorrect, car le Hub BGP est préféré à la sous-couche BGP.

• Problème 47664 :

  Dans une configuration Hub et Spoke où le mode site distant vers site distant via Hub VPN est désactivé, la tentative d'inversion du trafic site distant vers site distant à l'aide d'une route Résumé sur un commutateur/routeur L3 entraîne des boucles de routage.

  Solution : Configurez le VPN cloud pour activer le VPN site distant à site distant et sélectionnez Utiliser des Hubs pour le VPN (Use Hubs for VPN).

• Problème 47681 :

  Lorsqu'un hôte côté LAN d'un dispositif VMware SD-WAN Edge utilise la même adresse IP que l'interface WAN de ce dispositif Edge, la connexion entre l'hôte LAN et le WAN ne fonctionne pas.

• Problème 47787 :

  Un dispositif VMware SD-WAN Spoke Edge configuré avec une business policy de backhaul envoie de manière incorrecte le trafic via le chemin d'accès de la passerelle VMware SD-WAN Gateway si ce flux est initié du Hub Edge vers ce dispositif Spoke Edge.

• Problème 48166 :

  Un dispositif VMware SD-WAN Virtual Edge sur KVM n'est pas pris en charge lors de l'utilisation d'un système d'exploitation de virtualisation Ciena et le dispositif Edge subit des pannes récurrentes de service de plan de données.

• Problème 48175 :

  Un dispositif VMware SD-WAN Edge exécutant une version 3.4.2 formera une contiguïté OSPF sur un segment non global si le segment non global dispose d'une interface configurée dans la même plage d'adresses IP qu'une interface configurée sur le segment global

• Problème 48530 :

  Les dispositifs VMware SD-WAN Edge modèles 6x0 n'effectuent pas de négociation automatique pour les SFP en cuivre à triple vitesse (10/100/1 000 Mbits/s).

  Solution : Le dispositif Edge 520/540 prend en charge les SFP en cuivre à triple vitesse, mais ce modèle a été marqué pour fin de commercialisation au 1er trimestre 2021.

• Problème 48597 : Le BGP Neighborship à multihop ne reste pas actif si l'un des deux chemins vers l'homologue tombe en panne

  S'il existe un BGP Neighborship à multihop avec un homologue vers lequel il existe plusieurs chemins et si l'un d'entre eux tombe en panne, l'utilisateur remarque la panne du BGP Neighborship et ne s'active pas à l'aide d'autres chemins d'accès disponibles. Cela inclut également le cas du voisinage à bouclage d'adresse IP locale.

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

• Problème 48666 :

  Le calcul de MTU du chemin d'accès de la passerelle frontale IPsec ne prend pas en compte la surcharge IPsec de 61 octets, ce qui entraîne une annonce MTU plus élevée au client LAN et la fragmentation des paquets IPsec suivants.

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

• Problème 49172 :

  Une règle NAT basée sur une stratégie configurée avec le même sous-réseau NAT pour deux dispositifs VMware SD-WAN Edge différents ne fonctionne pas.

• Problème 49738 :

  Dans certains cas, lorsqu'un dispositif VMware SD-WAN Spoke Edge est configuré pour utiliser plusieurs dispositifs Hub Edge, le dispositif Spoke Edge peut ne pas former de tunnels vers l'un des Hubs configurés dans la liste de Hubs.

• Problème 50518 :

  Sur une passerelle VMware SD-WAN Gateway sur laquelle PKI est activée, si plus de 6 000 tunnels PKI tentent de se connecter à la passerelle, les tunnels peuvent ne pas s'afficher, car les SA entrants ne sont pas supprimés.

  Remarque : Les tunnels utilisant l'authentification par clé prépartagée (PSK) ne présentent pas ce problème.

• Problème 51428 : Une perte de trafic multicast peut être observée sur un site sur lequel une sous-interface est configurée avec PIM sur le dispositif VMware SD-WAN Edge.

  Lorsqu'une sous-interface configurée avec PIM est transférée d'un segment à un autre à la volée, pimd (le processus qui gère PIM) peut redémarrer et le site subit une perte de trafic multicast intermittente.

  Solution : Désactivez d'abord la sous-interface, puis transférez-la vers un autre segment. Après le transfert, réactivez la sous-interface.

• Problème 51436 : Pour un site utilisant la topologie de haute disponibilité améliorée lors du déploiement d'un dispositif VMware SD-WAN Edge à l'aide d'un modem LTE, le basculement de HA prend environ entre 5 et 6 minutes si le site passe à un état « split-brain ».

  Dans le cadre de la récupération à partir d'un état Split-Brain, les ports LAN sont désactivés sur le dispositif Edge actif et cela a une incidence sur le trafic LAN pendant la période d'inactivité des ports et jusqu'à la récupération du site.

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

• Problème 52483 : Si la underlay accounting est activée pour une interface, le dispositif VMware SD-WAN Edge retransfère à tort le trafic vers la même interface plutôt que de le transférer vers la superposition.

  Ce comportement est dû à un problème avec la underlay accounting et une résolution de route récursive.

  Solution : Désactivez la underlay accounting pour l'interface concernée.

• Problème 53219 : Après le rééquilibrage d'un cluster de Hub VMware SD-WAN, l'interface/IIF RPF ne sera peut-être pas définie correctement sur les quelques dispositifs Spoke Edge.

  Le trafic multicast sera affecté sur les dispositifs Spoke Edge concernés. Après un rééquilibrage du cluster, certains dispositif Edge Spoke ne parviennent alors pas à envoyer une jonction PIM.

  Solution : Ce problème persiste jusqu'au redémarrage du service Edge pour le dispositif Spoke Edge concerné.

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

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

• Problème 53359 : La session BGP/BFD peut échouer lors de certains scénarios d'attaques DDoS.

  Si le trafic est saturé depuis le client connecté à l'interface routée vers le client LAN, la session BGP/BFD peut échouer. En outre, lorsque le trafic de priorité élevée en temps réel est saturé vers la destination de superposition, la session BGP/BFD peut échouer.

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

• Problème 53830 : Sur un dispositif VMware SD-WAN Edge, les valeurs de préférence et d'annonce de certaines routes dans la vue BGP peuvent ne pas être appropriées lorsque l'indicateur DCC est activé. Cela génère un ordre de tri inadéquat dans la FIB du dispositif Edge.

  Lorsque le calcul du coût distribué (DCC, Distributed Cost Calculation) est activé dans un scénario mis à l'échelle avec un grand nombre de routes sur un dispositif Edge, certaines routes peuvent ne pas être correctement mises à jour avec les valeurs de préférence et d'annonce lors de l'examen d'un bundle de diagnostics du dispositif Edge pour le journal bgp_view.  S'il était détecté, ce problème serait une découverte dans quelques dispositifs Edge dans le cadre d'une grande entreprise (plus de 100 dispositifs Spoke Edge connectés à des dispositifs de Hub ou des clusters de Hub).  

  Solution : Ce problème peut être résolu en réapprenant les routes BGP de la sous-couche ou en effectuant une option Actualiser (Refresh) sur la page OFC de l'instance de VMware SD-WAN Orchestrator pour les routes concernées. Notez que l'exécution d'une option Actualiser (Refresh) d'une route réapprend les routes de tous les dispositifs Edge de l'entreprise.

• Problème 53934 : Dans une entreprise dans laquelle un cluster Hub VMware SD-WAN est configuré, si le Hub principal dispose de voisinages BGP à multihop côté LAN, le client peut subir des abandons de trafic sur un dispositif Spoke Edge en cas de panne de LAN ou lorsque BGP est désactivé sur tous les segments.

  Dans un cluster Hub, le Hub principal dispose d'un BGP Neighborship à multihop avec un périphérique homologue pour apprendre des routes. Si l'interface physique sur le Hub par lequel le BGP Neighborship est établi tombe en panne, les routes LAN BGP peuvent ne pas passer à zéro, bien que la vue BGP soit vide. Cela peut éviter le rééquilibrage du cluster Hub. Ce problème peut également être observé lorsque BGP est désactivé pour tous les segments et lorsqu'il existe un ou plusieurs voisinages BGP à multihop.

  Solution : Redémarrez le Hub dont le LAN était en panne (ou le protocole BGP désactivé).

• Problème 56218 : Pour un site client déployé avec une topologie haute disponibilité ou sur lequel la fonction HA vient d'être activée, lorsque les dispositifs Edge sont mis à niveau de la version 3.2.x vers la version 3.4.x, il se peut que le dispositif Edge en veille soit inactif.

  Lorsque la fonction HA est activée ou lorsque les dispositifs Edge HA sont mis à niveau de la version 3.2.2 vers la version 3.4.x après la configuration d'un paramètre WAN à l'aide de l'interface utilisateur locale, l'interface HA (par ex., LAN1 ou GE1 selon le modèle d'Edge) sera supprimée du dispositif Edge en veille et l'état HA sera défini sur HA_FAILED sur VMware SD-WAN Orchestrator.

  Solution : Redémarrer le dispositif Edge en veille pour le récupérer

• Problème 60006 : Lorsque la haute disponibilité (HA) est activée sur les dispositifs VMware SD-WAN Edge matériels tels que les modèles 620 et 640, le dispositif Edge en veille peut redémarrer.

  Lorsque la fonction HA est activée sur un modèle 620 ou 640 (ce sont les modèles sur lesquels ce problème a été observé), le dispositif Edge en veille peut détecter une alerte Actif/Actif et le dispositif Edge en veille redémarre pour corriger l'état Actif/Actif. Ce problème est dû aux éléments suivants : lors de l'initialisation d'Edge, il existe un risque de condition de concurrence entre l'initialisation de l'interface HA et l'initialisation de la machine d'état HA. En d'autres termes, la machine d'état HA démarre beaucoup plus tôt que l'initialisation du pilote d'interface HA et, par conséquent, la machine d'état HA ne détecte aucun signal de pulsation du dispositif Edge homologue et passe à l'état Actif.  Ce problème se produit rarement et, s'il se produit pour un site particulier, il est peu probable qu'il se produise deux fois dans la même session. En d'autres termes, le site n'est pas censé entrer dans un cycle sans fin de redémarrages du dispositif Edge en veille.

  Solution : il n'existe aucune solution à ce problème, mais en général, le dispositif en veille récupère après le premier redémarrage.

• Problème 60225 : Lors de l'exécution du diagnostic à distance « État de l'interface » (Interface Status) pour un dispositif VMware SD-WAN Edge, la sortie sur VMware SD-WAN Orchestrator pour les interfaces SFP affiche les informations de vitesse et de duplex incorrectes.

  Les données sur Orchestrator sont incorrectes pour les interfaces SFP. Par exemple, en affichant 0 Mbit/s ou semi-duplex en cas de visualisation directe sur le dispositif Edge, les données indiquent duplex intégral à 1 000 Mbit/s, ou une valeur semblable.

  Solution : il n'y a aucune solution.

• Problème 60523 : Le ping échoue sur une adresse IP de client acheminé en cas d'activation d'une sonde SLA.

  Le paquet de réponse ICMP ne parvient pas à être traité par le service de plan de données du dispositif Edge si une sonde SLA est activée pour l'adresse IP du client acheminé.  Sans le correctif, la seule façon de résoudre ce problème consistait à désactiver la sonde ICMP.

  Solution : désactivez la sonde ICMP.

• Problème 61361 : Lors de l'application d'une mise à jour logicielle pour mettre à niveau un dispositif VMware SD-WAN Edge 3400, 3800 ou 3810 vers le dispositif Edge version 3.4.5, 4.0.2 ou 4.2.1, il se peut que les modèles d'Edge ne démarrent pas immédiatement après la mise à jour.

  Les versions 3.4.5, 4.0.2 et 4.2.1 incluent une mise à jour du microprogramme particulière pour le périphérique logique programmable complexe (CPLD), et la mise à jour déclenche un redémarrage qui peut parfois être « bloqué », ce qui nécessite un cycle d'alimentation manuel pour redémarrer le système.

  Solution : Relancez manuellement le cycle d'alimentation du dispositif Edge pour terminer la mise à jour.

• Problème 61543 : En cas de configuration de plusieurs règles NAT 1:1 sur différentes interfaces disposant de la même adresse IP interne, le trafic entrant peut être reçu sur une seule interface et les paquets sortants du même flux peuvent être acheminés via une interface différente.

  Pour les flux NAT de l'extérieur vers l'intérieur, les règles NAT 1:1 sont mises en correspondance avec l'adresse IP externe et l'interface sur laquelle les paquets sont reçus. Pour les paquets sortants du même flux, le dispositif VMware SD-WAN Edge tente à nouveau de faire correspondre les règles NAT en comparant l'adresse IP interne. Le trafic sortant peut alors être acheminé via l'interface configurée dans la première règle correspondante avec l'option Trafic sortant (Outbound Traffic) activée.

  Solution : il n'existe aucune solution à ce problème en dehors de la vérification de la configuration d'une seule règle NAT 1:1 avec une adresse IP interne particulière.

• Problème 62552 : Un site peut subir des périodes intermittentes de perte élevée de paquets et de problèmes de connectivité.

  Cela provient du fait que l'API vérifie la résolution ARP en indiquant au dispositif Edge une résolution ARP réussie d'un périphérique tout en transmettant une adresse MAC de 00:00:00:00.  Cette adresse est conservée dans le cache ARP et tous les paquets destinés au périphérique sur lequel l'adresse MAC est répertoriée comme étant zéro sont abandonnés.  Dans ce problème, de nombreuses instances d'ARP réussies sans adresse MAC sont transmises, ce qui entraîne une perte élevée de paquets et des problèmes de connectivité.

  Remarque : le problème 60130 et ce problème ont le même comportement sous-jacent et une cause identique, mais les correctifs attendus pour chaque ticket diffèrent. Le problème 60130 aura un correctif défensif, tandis que le problème 62552 aura un correctif complet qui empêche toute récurrence de ce problème.

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

• Problème 63359 : Pour un site configuré avec une topologie de haute disponibilité et OSPF et où les dispositifs VMware SD-WAN Edge utilisent une build de dispositif Edge d'adresse IP de gestion, lorsque ces dispositifs Edge sont mis à niveau d'une build d'adresse IP de gestion 3.4.x vers une version 4.2.x, la connectivité OSPF peut être interrompue après la mise à niveau. 

  Lorsque les dispositifs Edge HA sont mis à niveau vers une build d'adresse IP de gestion 4.2.x, les systèmes HA peuvent définir leur ID de routeur comme 169.254.2.2. Il ne s'agit pas du comportement attendu, car la sélection Edge de l'ID de routeur ne doit pas prendre en compte l'adresse IP de l'interface HA. Cet ID de routeur interrompt la connectivité OSPF et une déconnexion complète se produit, car l'échange de route ne se produit plus.

  Solution : redémarrez le service Edge (déclenchement d'un basculement HA), car cela forcera une nouvelle sélection de l'ID de routeur qui doit être correct après le redémarrage.

• Problème 67790 : Pour une entreprise cliente qui utilise BGP ou OSPF et qui a configuré un ou plusieurs filtres entrants pour ignorer certaines routes, lorsque le calcul du coût dynamique (DCC) est activé sur cette entreprise, le ou les filtres entrants ne seront plus appliqués et le trafic tentera d'utiliser ces routes.

  Avant l'activation de DCC, la base d'informations de transfert (FIB) n'inclut pas les routes qui ont été définies sur IGNORE sur le filtre entrant BGP/OSPF.  Une fois DCC activé, la base d'informations de transfert inclut désormais ces routes et le trafic tentera d'utiliser ces routes avec un potentiel d'interruption de trafic significatif pour l'entreprise du client.  

  Solution : OSPF/BGP doit être redémarré pour que le filtre entrant soit appliqué correctement.

• Problème 84825 : Pour un site déployé avec une topologie à haute disponibilité dans laquelle BGP est configuré, le client peut observer le basculement continu de la paire de dispositifs Edge HA sans récupération possible si le site possède plus de 512 règles « match » et « set » BGPv4 configurées.

  Le concept « Plus de 512 règles match et set BGPv4 » s'interprète comme un client qui configure plus de 256 règles dans le filtre entrant et 256 règles dans le filtre sortant. Ce problème peut perturber le client, car le basculement répété entraîne l'abandon continu des flux de trafic en temps réel, tels que les appels vocaux, puis leur recréation. Lorsque les dispositifs Edge HA rencontrent ce problème, le processus de synchronisation des threads de CPU Edge échoue, ce qui entraîne le redémarrage du dispositif Edge à des fins de récupération. Toutefois, le dispositif Edge promu rencontre également le même problème et redémarre à son tour sans récupération atteinte sur le site.

  Solution : Sans correctif pour ce problème, le client doit s'assurer qu'il n'existe pas plus de 512 règles match et set BGPv4 configurées pour un site HA.

  Si le site rencontre ce problème et possède plus de 512 règles match et set BGP/v4 configurées, le client doit immédiatement réduire le nombre de règles à 512 au maximum pour récupérer le site.

  Si le client doit disposer de plus de 512 règles match et set BGPv4, il peut également rétrograder les dispositifs Edge HA vers la version 3.4.6 dans le cas où ce problème ne se produit pas, mais au coût des fonctionnalités Edge trouvées dans les versions ultérieures. Cela ne peut s'effectuer que si son modèle d'Edge est pris en charge dans la version 3.4.6 et le client doit confirmer cela avant la rétrogradation.

Problèmes connus d'Orchestrator

• Problème 19566 :

  Après un basculement haute disponibilité, le numéro de série du dispositif VMware SD-WAN Edge en veille peut être affiché comme numéro de série actif dans Orchestrator.

• Problème 21342 :

  Lors de l'attribution de passerelles partenaires par segment, la liste des attributions de passerelle peut ne pas s'afficher sous l'option d'opérateur Afficher (View) dans la liste de surveillance du dispositif VMware SD-WAN Edge.

• Problème 24269 :

  Surveiller (Monitor) > Transport > Perte (Loss) n'indique pas dans le graphique la perte de liaison WAN observée tandis que les graphiques QoE reflètent cette perte. 

• Problème 25932 :

  VMware SD-WAN Orchestrator permet la suppression de passerelles VMware SD-Gateway du pool de passerelles, même lorsqu'elles sont en cours d'utilisation.

• Problème 32335 :

  La page Contrat de service de l'utilisateur final (End User Service Agreement) (CSUF) génère une erreur lorsqu'un utilisateur tente d'accepter le contrat.

  Solution : Assurez-vous qu'aucun espace de début ou de fin n'est présent dans le nom de l'entreprise.

• Problème 32435 :

  Un remplacement du dispositif VMware SD-WAN Edge pour une configuration NAT basée sur des stratégies est autorisé pour les tuples qui sont déjà configurés au niveau du profil et inversement.

• Problème 32856 :

  Bien qu'une business policy soit configurée pour utiliser le cluster de Hubs pour le backhaul du trafic Internet, l'utilisateur peut annuler la sélection du cluster de Hubs d'un profil sur une instance de VMware SD-WAN Orchestrator qui a été mise à niveau de la version 3.2.1 vers la version 3.3.x.

• Problème 32913 :

  Après l'activation du mode haute disponibilité, les détails de la multicast du dispositif VMware SD-WAN Edge ne s'affichent pas sur la page Surveillance (Monitoring). Un basculement résout le problème.

• Problème 33026 :

  La page Contrat de service de l'utilisateur final (End User Service Agreement) (CSUF) ne se recharge pas correctement après la suppression de l'accord.

• Problème 34828 :

  Le trafic ne peut pas passer entre un dispositif VMware SD-WAN Spoke Edge utilisant la version 2.x et un dispositif Hub Edge utilisant la version 3.3.1.

• Problème 35658 :

  Lorsqu'un dispositif VMware SD-WAN Edge est déplacé d'un profil vers un autre qui a un paramètre CSS différent (par exemple, IPsec dans le profil 1 vers GRE dans profil 2), les paramètres CSS de niveau Edge continueront à utiliser les paramètres CSS précédents (par exemple, IPsec et non GRE). 

  Solution : Désactivez, puis réactivez GRE au niveau du dispositif Edge pour résoudre ce problème.

• Problème 35667 :

  Lorsqu'un dispositif VMware SD-WAN Edge est déplacé d'un profil vers un autre avec le même paramètre CSS, mais un nom CSS GRE différent (les mêmes points de terminaison), certains tunnels GRE ne s'affichent pas dans la surveillance.

  Solution : Désactivez, puis réactivez GRE au niveau du dispositif Edge pour résoudre ce problème.

• Problème 36665 :

  Si VMware SD-WAN Orchestrator ne peut pas accéder à Internet, les pages de l'interface utilisateur qui nécessitent l'accès à l'API Google Maps peuvent ne pas se charger complètement.

• Problème 38056 :

  Le fichier Edge-Licensing export.csv n'affiche pas les données de la région.

• Problème 38843 :

  Lors du transfert d'un mappage d'application, il n'y a pas d'événement d'opérateur et l'événement de dispositif Edge est d'utilité limitée.

• Problème 39633 :

  Le lien hypertexte de la superpasserelle ne fonctionne pas lorsqu'un utilisateur affecte la passerelle secondaire comme superpasserelle.

• Problème 39790 :

  VMware SD-WAN Orchestrator permet à un utilisateur de configurer une interface routée d'un dispositif VMware SD-WAN Edge sur une valeur supérieure aux 32 sous-interfaces prises en charge, ce qui crée le risque qu'un utilisateur puisse configurer 33 sous-interfaces ou plus sur une interface, ce qui entraîne l'échec du service de plan de données pour le dispositif Edge.

• Problème 40341 :

  Bien que l'application Skype soit correctement classée sur le serveur principal en tant que trafic en temps réel, lors de la modification de la Business Policy Skype sur VMware SD-WAN Orchestrator, la classe de service peut indiquer par erreur Transactionnel (Transactional).

• Problème 41691 :

  L'utilisateur ne peut pas modifier le champ Nombre d'adresses (Number of addresses), bien que le pool DHCP ne soit pas épuisé sur la page Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device).

• Problème 43276 :

  L'utilisateur ne peut pas modifier le type de segment lorsqu'une passerelle partenaire est configurée pour un dispositif ou un profil VMware SD-WAN Edge.

• Problème 44153 :

  VMware SD-WAN Orchestrator n'envoie pas systématiquement d'e-mails d'alerte aux adresses e-mail configurées dans la section Alertes et notifications (Alerts and Notifications).

• Problème 46254 :

  Lors de l'activation d'un dispositif VMware SD-WAN Edge, VMware SD-WAN Orchestrator ne détecte pas de MTU de liaison WAN modifiée ou la présence d'un ID VLAN pour les interfaces configurées par DHCP.

• Problème 47269 :

  L'interface VMware SD-WAN 510-LTE peut s'afficher pour les modèles d'Edge qui ne prennent pas en charge une interface LTE.

• Problème 47713 :

  Si une règle de Business Policy est configurée alors que le VPN cloud est désactivé, la configuration NAT doit être reconfigurée lors de l'activation du VPN cloud.

• Problème 47820 :

  Si la configuration de VLAN prévoit la désactivation de DHCP au niveau du profil, tout en ayant prévoyant également un remplacement Edge pour ce VLAN sur ce dispositif Edge, alors que DHCP est activé et qu'une entrée pour le champ Serveur DNS (DNS server) est définie sur Aucun (None) (aucune adresse IP n'est configurée), l'utilisateur ne pourra pas modifier la page Configurer (Configure) > Dispositif Edge (Edge) > Périphérique (Device) et obtiendra le message d'erreur Adresse IP non valide [] (Invalid IP address []) qui n'identifie pas le problème réel et ne l'explique pas.

• Problème 48085 :

  VMware SD-WAN Orchestrator permet à un utilisateur de supprimer un VLAN associé à une interface.

• Problème 48737 :

  Sur une instance de VMware SD-WAN Orchestrator qui utilise la nouvelle interface utilisateur de la version 4.0.0, si un utilisateur se trouve sur une page Surveiller (Monitor) et change l'intervalle de début et de fin, puis qu'il navigue entre les onglets, Orchestrator ne met pas à jour l'intervalle de début et de fin sur aux nouvelles valeurs.

• Problème 49225 :

  VMware SD-WAN Orchestrator n'applique pas la limite d'un total de 32 VLAN.

• Problème 49790 :

  Lorsqu'un dispositif VMware SD-WAN Edge est activé dans la version 4.0.0, l'activation est publiée deux fois dans les événements.

  Solution : Ignorez l'événement en double.

• Problème 50531 :

  Lorsque deux opérateurs ayant des privilèges différents utilisent la même fenêtre de navigateur lors de l'accès à la nouvelle interface utilisateur de la version 4.0.0 de VMware SD-WAN Orchestrator, et que l'opérateur disposant de privilèges moindres tente de se connecter après l'opérateur disposant de privilèges plus élevés, cet opérateur disposant de privilèges inférieurs observe plusieurs erreurs indiquant que l'utilisateur ne dispose pas du privilège (user does not have privilege).

  Remarque : Il n'y a aucune escalade de privilèges pour l'opérateur ayant des privilèges inférieurs, uniquement l'affichage des messages d'erreur.

  Solution : L'opérateur suivant peut actualiser cette page avant de se connecter afin d'éviter de voir les erreurs ou chaque opérateur peut utiliser des fenêtres de navigateur différentes pour éviter ce problème d'affichage.

• Problème 51722 : Dans la version 4.0.0 de VMware SD-WAN Orchestrator, le sélecteur de plage de temps n'est pas supérieur à deux semaines pour les statistiques dans les onglets Surveiller (Monitor) > Dispositif Edge (Edge).

  Le sélecteur de plage de temps n'affiche pas les options supérieures à « 2 dernières semaines » (Past 2 Weeks) dans les onglets Surveiller (Monitor) > Dispositif Edge (Edge), même si la période de rétention d'un ensemble de statistiques est bien supérieure à 2 semaines.  Par exemple, les statistiques de flux et de liaisons sont conservées par défaut pendant 365 jours (ce qui est configurable), tandis que les statistiques de chemins ne sont conservées que pendant 2 semaines par défaut (également configurable).  Ce problème consiste à faire en sorte que tous les onglets de Surveiller (Monitor) soient conformes au type de statistique le plus faible conservé et à permettre à un utilisateur de sélectionner une période cohérente avec la période de rétention de cette statistique.

  Solution : Un utilisateur peut utiliser l'option « Personnalisé » (Custom) dans le sélecteur de plage de temps pour consulter les données pendant plus de 2 semaines.

• Problème 60039 : La réactivation du numéro RMA ne fonctionne pas lorsque le modèle de dispositif VMware SD-WAN Edge est modifié.

  Lorsque vous effectuez une réactivation du numéro RMA pour un site sur lequel le modèle d'Edge est également en cours de modification, VMware SD-WAN Orchestrator n'enregistre pas la modification du modèle, ce qui rend le lien de réactivation non fonctionnel. Cela affecte uniquement les réactivations du numéro RMA en cas de modification du modèle d'Edge. Une réactivation du numéro RMA, dans le cadre de laquelle le modèle d'Edge reste le même, fonctionnera comme prévu.

  Solution : Si vous utilisez un modèle d'Edge différent pour un site, l'utilisateur devra créer un nouveau dispositif Edge et appliquer manuellement tous les paramètres spécifiques au dispositif Edge.