Citrix SD-WAN

Notes de publication

Cette note de mise à jour décrit les problèmes connus et les problèmes résolus applicables au logiciel Citrix SD-WAN version 10.2 version 3 pour SD-WAN Standard Edition, WANOP, Premium Edition appliances et SD-WAN Center.

Pour plus d’informations sur les versions précédentes, consultez la documentation de Citrix SD-WAN.

Nouveautés

**NSSDW-2011:6100 nouvelle plate-forme introduite pour remplacer le matériel 5100. Le SD-WAN 6100 Standard Edition (SE) est un appareil 2U. Chaque modèle dispose de deux processeurs 14 cœurs pour un total de 28 cœurs physiques (avec hyper-threading activé) et 256 Go de mémoire.

NSSDW-17381 : Prise en charge de la capacité de diffusion IP dirigée sur les appareils SD-WAN. L’objectif de la fonctionnalité de diffusion dirigée par IP est d’atteindre le sous-réseau cible avec les paquets de diffusion sans diffuser sur l’ensemble du réseau.

NSSDW-17785 : Activer RED pour le trafic ICA par défaut. Étant donné que les règles QoS d’application ont priorité sur les règles QoS IP, la fonctionnalité HDX Fair Sharing a été désactivée par défaut. Activez RED pour vous assurer qu’aucun utilisateur HDX ne consomme plus qu’une part équitable de la bande passante réseau disponible en cas de congestion.

NSSDW-18707 : 100 Mbps SFP et E1T1 SFP sont maintenant pris en charge sur la plate-forme 1100.

Problèmes résolus

SDWANHELP-654 (78620706) : L’appliance SD-WAN WANOP 4000 peut se bloquer lors de l’analyse des connexions ICA.

SDWANHELP-725 (78779804) : L’appliance SD-WAN envoie les informations de chemin virtuel HA au centre SD-WAN et renvoie une erreur de statistiques car elle est incapable de les reconnaître.

SDWANHELP-742 (78825507) : le service SD-WAN peut se bloquer pendant la collecte de bundle STS lorsque le nombre de règles QoS d’application dépasse les règles QoS basées sur IP.

SDWANHELP-746 (78827291) : Lors de la création de deux règles de pare-feu différentes, une erreur d’audit peut se produire si une adresse IP et un numéro de port sont identiques, même si les protocoles sont différents.

SDWANHELP-768 (78860524) : 5100 Premium Edition (PE) Virtual WAN Service redémarre lors de l’établissement du canal de signalisation. Il se produit en raison d’un conflit de port éphémère entre plusieurs moteurs de paquets WANOP.

SDWANHELP-778 (78876692) : le service SD-WAN peut se bloquer dans un scénario en raison d’une situation indésirable lorsque le site intermédiaire est activé dans la configuration.

SDWANHELP-795 (78859346) : Le test de bande passante de chemin en cours d’exécution se bloque, si :

  • Le test de bande passante de chemin est exécuté sur les branches qui sont isolées du MCN en raison du chemin virtuel est désactivé/désactivé.
  • Le MCN effectue le changement de propriété de lien WAN de succursale, lorsque les succursales viennent.

SDWANHELP-799 (78893894) : Le SD-WAN apprend les préfixes OSPF avec coût « AS IS » des routeurs voisins et permet l’exportation de ceux-ci vers des périphériques SD-WAN homologues. Si le coût de redistribution est modifié en externe sur le routeur voisin (par exemple, redistribution BGP/RIP dans le changement de coût de mesure OSPF), le coût nouvellement modifié est mis à jour uniquement sur le périphérique SD-WAN immédiatement connecté, mais pas sur les périphériques SD-WAN homologues.

SDWANHELP-801 (78899126, 78938744) : Le service SD-WAN peut se bloquer lors du traitement de paquets ICMP sur son IP virtuelle à haut débit et la mise à jour de configuration est déclenchée simultanément.

SDWANHELP-808 (78866821) : Pour des raisons héritées, SD-WAN n’autorise pas peu de modèles dans la configuration du site. Ce site particulier contient APN dans son nom. Il est trompeur uniquement dans l’interface graphique SD-WAN et n’affecte aucune opération au niveau du site.

SDWANHELP-812 (78862423, 78937011) : Le provisioning 10.2.x échoue sur la plate-forme 1100 PE car il n’a pas créé de disque DBC.

SDWANHELP-818 : Une fois que les routes dynamiques ont appris et convergé, si une mise à jour de configuration a lieu et qu’un changement de coût est effectué, après l’activation, l’ID de route des routes apprises dynamiquement est réinitialisé à ‘0’ au lieu de rester énuméré provoquant même la suppression des itinéraires optimaux dans une mise à jour de l’itinéraire vers le voisin.

SDWANHELP-830 : Les certificats d’autorité de certification utilisés pour l’appairage auto-sécurisé dans SD-WAN WANOP sont supprimés lors de la mise à niveau. Cela a un impact sur la formation d’appairage sécurisé pour tous les nouveaux périphériques ajoutés au déploiement. Dans ce cas, il est nécessaire de régénérer les certificats d’autorité de certification, de supprimer les certificats et les paires de clés de certificat de tous les sites et de rétablir l’appairage de sécurité automatique une fois de plus après la mise à niveau vers la version 10.2.3.

SDWANHELP-846 (78958288) : le service SD-WAN peut se bloquer lors de la réception de paquets ICMP destinés à l’IP virtuelle dans un déploiement de plusieurs domaines de routage.

NSSDW-19233 : L’agent Windows Azure se remplit de partition racine car peu d’extensions sont installées par le portail Azure.

NSSDW-17168 : Dans le déploiement du mode HA Azure, lorsqu’une appliance distante est derrière NAT (dans les scénarios LTE), il est observé que l’apprentissage du port source distant ne se produit pas et que le chemin virtuel n’est pas établi.

NSSDW-18617 (78807883) : La configuration d’itinéraire réseau est prise en charge pour diriger le trafic vers le service Zscaler. Auparavant, l’intégration du SD-WAN Zscaler permettait uniquement de diriger le trafic Internet vers les points de terminaison Zscaler. Les routes d’application ont une priorité plus élevée que les routes réseau. Dans ce cas, certains trafics de chemins virtuels ont été redirigés sur Internet. La prise en charge des routes réseau pour la redirection du trafic Zscaler permettrait de s’assurer qu’aucun trafic de chemin virtuel n’est envoyé à Internet.

Problèmes connus

SDWANHELP-786 (78714443) : Sur un site de succursale (traduction d’adresses IP CGNAT/Public) communiquant avec MCN, si le poinçonnage de trous UDP est activé après la poussée de configuration initiale, la configuration ne sera pas mise à jour tant que le service ne sera pas redémarré. Par conséquent, le MCN ne mettra pas à jour les détails du port vers d’autres branches. Cela provoque les chemins d’être dans l’état « mort ».

  • Solution : redémarrez le MCN.

  • Recommandation : Si les branches sont Nat’ed, il est préférable d’activer le poinçonnage UDP dans le cadre de la configuration initiale pour activer les chemins virtuels directs entre les deux branches.

NSSDW-20101 : Problème avec le type de service IP_Host dans les filtres d’exportation - Une fois que les routes dynamiques ont été apprises et convergées, si une mise à jour de configuration a lieu avec un changement de coût effectué, après l’activation, les ID de route des routes apprises dynamiquement sont réinitialisés à ‘0’ au lieu de rester énuméré provoquant même des itinéraires optimaux à supprimer dans une mise à jour de l’itinéraire vers le voisin.

  • Solution : une solution de contournement temporaire consisterait à arrêter l’apprentissage et la propagation des routes/32 depuis le contrôleur de domaine vers la branche.

  • Recommandation : Si vous utilisez le type de service IP_Host dans les filtres d’exportation, ne mettez pas à niveau vers 10.2.x. Le problème sera résolu dans la prochaine version.

Notes de publication