Qualité de l’expérience applicative
Qualité de l’expérience applicative (AppQoE)
- Introduction à la qualité de l’expérience applicative
- Avantages de la qualité de l’expérience applicative
- Limitations
- Comment fonctionne la qualité de l’expérience applicative ?
- Comment la qualité de l’expérience applicative mesure les performances des applications
- Commutation du trafic applicatif vers un autre chemin
Introduction à la qualité de l’expérience applicative
La croissance incessante du cloud computing, de la mobilité et des applications Web exige que le réseau identifie et contrôle le trafic au niveau applicatif, et gère chaque type d’application séparément pour fournir une qualité d’expérience (QoE) aux utilisateurs. Pour garantir une QoE spécifique aux applications (AppQoE), vous devez hiérarchiser, isoler et acheminer efficacement le trafic applicatif sans compromettre les performances ou la disponibilité.
AppQoE utilise (ou utilise) les capacités de deux services de sécurité des applications : l’identification des applications (AppID) et le routage avancé basé sur les stratégies (APBR). Il utilise AppID pour identifier des applications spécifiques dans votre réseau et un routage avancé basé sur des stratégies (APBR) pour spécifier un chemin pour certains trafic en associant des profils SLA à une instance de routage sur laquelle le trafic applicatif est envoyé conformément aux règles APBR.
L’une des exigences importantes d’un SD-WAN (SD-WAN) est de mesurer la qualité des chemins réseau sous-jacents et, en fonction des résultats, de déterminer les meilleurs chemins à utiliser pour la livraison de chaque paquet. AppQoE surveille les performances des applications stratégiques et, en fonction du score, sélectionne la meilleure liaison possible pour ce trafic applicatif afin de répondre aux exigences de performances spécifiées dans l’accord de niveau de service (SLA).
La présence d’une règle SLA dans la configuration APBR déclenche la fonctionnalité AppQoE ; S’il n’y a pas de profils SLA disponibles, l’APBR fonctionne sans déclencher AppQoE.
Cas d’utilisation pris en charge
Vous pouvez configurer AppQoE de manière optimale à l’aide de Contrail Service Orchestration (CSO). Nous vous recommandons d’utiliser CSO pour configurer AppQoE pour la solution Contrail SD-WAN de Juniper Networks. Pour plus de détails, consultez la présentation de la qualité de l’expérience des applications et configurer et surveiller la qualité de l’expérience des applications.
Équipements SRX Series pris en charge
AppQoE est pris en charge à la fois sur les topologies de hub-and-spoke et de maillage complet dans les déploiements SD-WAN.
Vous pouvez configurer des instances vSRX, des équipements de la ligne SRX300, SRX550M en tant qu’équipements en étoile et SRX1500, SRX4100 et SRX4200 en tant qu’équipements hub.
Vous pouvez configurer un AppQoE entre deux points de terminaison d’équipements SRX Series (en fin de livre) et les deux équipements SRX Series doivent avoir la même version de l’image de Junos OS.
À partir de la version Junos OS 15.1X49-D160 et de Junos OS 19.1R1, les équipements SRX4100 et SRX4200 prennent en charge AppQoE lorsque les équipements sont en mode cluster de châssis. Vous pouvez configurer l’équipement pour qu’il fonctionne à la fois en mode actif/actif et en mode actif/passif, et le déployer en tant qu’équipement en réseau dans les déploiements SD-WAN.
Avantages de la qualité de l’expérience applicative
Permet une QoE rentable en fournissant une surveillance en temps réel du trafic applicatif pour fournir un niveau de service cohérent et prévisible.
Augmente la fidélisation et la satisfaction des clients en fournissant un SLA garanti pour la livraison de certains trafics (comme le trafic vidéo). AppQoE garantit que le trafic approuvé reçoit la priorité appropriée et la bande passante requise pour garantir la meilleure qualité d’expérience à l’utilisateur.
Limitations
L’implémentation d’AppQoE sur les équipements de sécurité présente les limites suivantes :
Toutes les différentes routes vers la destination via différentes interfaces doivent avoir les mêmes préférences, le même poids et les mêmes mesures configurées. Tous les routes doivent être ajoutées en tant que chemins ECMP pour la destination et doivent également faire partie de la même table de transfert.
Le service SLA AppQoE uniquement entre deux terminaux d’équipements de sécurité (en fin de livre) est pris en charge. Le service SLA AppQoE de bout en bout n’est pas pris en charge.
AppQoE ne peut être appliqué que si toutes les interfaces font partie de la même zone.
AppQoE ne peut pas être appliqué pour le trafic inversé.
AppQoE n’influence pas le changement dans la destination d’une session.
AppQoE ne prend pas en charge l’encapsulation de sonde IPv6/UDP, GRES, le cluster de châssis (ISSU, la haute disponibilité, la haute disponibilité CPE double, la haute disponibilité en mode Z) et les systèmes logiques.
AppQoE ne prend pas en charge la sélection des chemins préférés et le routage et le transfert virtuels de transit (VRF) ne sont pas pris en charge.
AppQoE ne prend pas en charge l’analyse passive sur les paquets de données IPv6.
Un filtre de pare-feu d’entrée est requis au niveau des interfaces non WAN pour éliminer les paquets UDP avec le port de destination UDP 36000.
L’équipement SRX4600 présente les limites suivantes :
La classe de service (CoS) pour l’encapsulation de routage générique (GRE) n’est pas prise en charge lorsque AppQoE est configuré.
Les détails des sondes passives peuvent ne pas être disponibles pour chaque session de courte durée.
La synchronisation des états de session peut ne pas avoir lieu sur le nœud secondaire en mode Z-line traitement du trafic lorsque l’équipement fonctionne en mode cluster de châssis.
Comment fonctionne la qualité de l’expérience applicative ?
AppQoE utilise les fonctionnalités AppID et APBR pour identifier des applications/groupes d’applications spécifiques et spécifier un chemin pour certains trafics en associant des profils SLA à une instance de routage sur laquelle le trafic applicatif est envoyé conformément aux règles APBR.
AppQoE surveille les performances des applications et, en fonction du score, sélectionne la meilleure liaison possible pour ce trafic applicatif afin de répondre aux exigences de performances spécifiées dans le SLA (accord de niveau de service).
- Identification des applications ou des groupes d’applications
- Spécification du chemin pour les applications ou les groupes d’applications
- Sélection des chemins de trafic applicatif
Identification des applications ou des groupes d’applications
Les étapes suivantes permettent d’identifier les applications ou les groupes d’applications :
L’identification des applications Junos OS identifie les applications et une fois qu’une application est identifiée, ses informations sont enregistrées dans le cache système d’application (ASC).
L’APBR évalue les paquets en fonction de la session pour déterminer si elle est candidate au routage basé sur les applications (routage avancé basé sur des stratégies). S’il s’agit du premier paquet de la nouvelle session et que le trafic n’est pas signalé pour le routage basé sur les applications, il subit un traitement normal (route non APBR) vers la destination.
Si la session a besoin d’un routage basé sur les applications, APBR interroge le module ASC pour obtenir les attributs de l’application (adresse IP, port de destination, type de protocole et service).
-
Si l’application dans ASC est trouvée, le trafic est ensuite traité pour obtenir une règle de correspondance dans le profil APBR.
-
Si une règle correspondante est trouvée, le trafic est redirigé vers l’instance de routage spécifiée pour la recherche de route.
-
AppQoE vérifie si un SLA est activé pour une session. Si la session est candidate pour une mesure SLA, AppQoE lance des sondes actives et passives pour mesurer les performances.
-
Si le SLA n’est pas activé pour la session dans la règle APBR, AppQoE ignore cette session et le comportement par défaut de l’APBR est appliqué à ces sessions, c’est-à-dire que le trafic est acheminé via l’instance de routage spécifiée pour la destination.
-
Si l’application n’est pas trouvée dans ASC, l’APBR demande une inspection approfondie du flux. c’est-à-dire que le package de signature d’application est installé et que l’identification de l’application est activée pour la session, de sorte que l’ASC peut être rempli pour être utilisé par les sessions suivantes pour le traitement APBR (voir étape 2).
-
Spécification du chemin pour les applications ou les groupes d’applications
Les étapes suivantes résument comment AppQoE spécifie un chemin pour le trafic applicatif en fonction des règles sla.
L’APBR utilise les détails de l’application pour rechercher une règle correspondante dans le profil APBR (profil d’application). Le trafic correspondant aux applications et aux groupes d’applications est transféré vers le routage statique et l’adresse du saut suivant, comme spécifié dans l’instance de routage.
Une règle SLA associée au profil APBR spécifie les paramètres nécessaires pour mesurer le SLA et identifier si une violation des SLA a eu lieu ou non.
Le trafic des applications est assigné à une liaison overlay particulière en fonction des métriques SLA de cette liaison overlay mesurées à l’aide d’un sondage actif.
La violation des SLA est déterminée par l’analyse passive du trafic des applications/groupes d’applications en direct. La meilleure liaison chemin/overlay pour le groupe d’applications/applications est déterminée à l’aide de l’algorithme de sélection des chemins.
Sélection des chemins de trafic applicatif
Les étapes suivantes ont lieu pour le routage du trafic de données de la source à la destination, en particulier pour sélectionner le meilleur chemin,
Pour le premier paquet de données d’un flux (premier chemin), si l’application est déjà connue (à partir de la recherche ASC), alors le meilleur chemin pour l’application est recherché dans la base de données. Si l’application n’est pas connue ou est nouvelle (à partir de la recherche ASC), choisissez un chemin aléatoire ou le chemin par défaut. Ce chemin se poursuit pendant toute la session. Plus tard, une fois l’application détectée par le DPI, la base de données est mise à jour avec le meilleur chemin pour l’application.
Pour le paquet de données restant d’un flux (chemin rapide), si l’application n’est pas connue initialement, alors la session particulière continue sur le même chemin. Si l’application est connue au départ, AppQoE sélectionne le meilleur chemin pour le trafic applicatif.
Lorsqu’une nouvelle application est détectée, le mécanisme de sélection des chemins tente de trouver un chemin qui répond à toutes les mesures sla. Si aucun chemin de ce type n’existe, alors le meilleur chemin suivant (en fonction du nombre de mesures satisfaites) est utilisé. Si plusieurs chemins répondent aux métriques, un chemin aléatoire est sélectionné parmi les chemins disponibles. La violation des SLA est détectée lorsque l’une des mesures est violée ou qu’aucune des mesures ne répond aux exigences, en fonction de la configuration du profil.
Comment la qualité de l’expérience applicative mesure les performances des applications
Les performances des applications sont déterminées par les indicateurs suivants :
Latence : temps physiquement requis pour le déplacement des supports en fonction de la longueur et de la distance à couvrir
RTT : un temps aller-retour requis pour se déplacer de la source à la destination et vice versa.
Perte de paquets : la perte de paquets reflète le nombre de paquets perdus par 100 paquets envoyés par un hôte.
Gigue : la gigue est la différence dans la latence d’un paquet à l’autre. La gigue entrante, la gigue sortante et la gigue à double sens peuvent être spécifiées pour évaluer les performances de la liaison.
AppQoE surveille la RTT, la gigue et la perte de paquets sur chaque liaison, et en fonction du score, redirige de manière transparente les applications vers le chemin alternatif si les performances de la liaison principale sont inférieures aux niveaux acceptables spécifiés par le SLA. La mesure et la surveillance des performances des applications sont effectuées à l’aide de sondes actives et passives afin de détecter les violations de SLA et de sélectionner un autre chemin pour cette application particulière.
AppQoE collecte des données en temps réel en surveillant en permanence le trafic applicatif et en identifiant les problèmes de réseau ou d’équipement :
Surveillance des performances sur toutes les liaisons overlay configurées.
Utiliser des sondes passives (inline avec le chemin de données de l’application) et des sondes actives (sondes synthétiques pour une application spécifique) pour surveiller les performances du trafic pour l’application ou le groupe d’applications.
Envoi de toutes les métriques de performances ou métadonnées collectées à des fins d’analyse à un collecteur de journaux.
Comparaison de l’application spécifiée avec une métrique de performances spécifique et modification dynamique du chemin du trafic applicatif en cas de violation des SLA.
Prise en charge d’une configuration métrique SLA flexible pour une application ou un groupe d’applications donné.
AppQoE mesure le SLA applicatif sur plusieurs liaisons WAN et mappe le trafic applicatif à un chemin parmi les liaisons disponibles, c’est-à-dire au chemin qui répond le mieux aux exigences des SLA.
Mesure des performances des applications à l’aide de sondes actives et passives
Les mesures actives et passives par sonde sont les deux approches utilisées pour l’analyse de bout en bout du réseau.
Sonde active : les sondes actives mesurent la qualité de service de l’application pour mesurer de bout en bout les performances du réseau.
Lors du sondage actif, des paquets personnalisés sont envoyés entre les points en étoile et les points de hub sur tous les routes multiples et le RTT, la latence, la gigue et la perte de paquets sont mesurées entre les points de sonde installés. Les sondes actives sont envoyées régulièrement sur toutes les liaisons actives et passives. Un nombre d’échantillons configuré est collecté et une moyenne en cours d’exécution pour chaque chemin de sonde de chaque application est mesurée. S’il y a une violation détectée pour un trafic applicatif, les métriques de la sonde sont évaluées afin de déterminer la meilleure liaison qui respecte le SLA.
Sonde passive : des sondes passives sont installées sur les liaisons du réseau et surveillent tout le trafic qui transite par ces liaisons.
L’analyse passive surveille les liens pour les violations des SLA sur le trafic de données en direct. Dans une sonde passive, les paquets de données réels sont encapsulés dans un en-tête de sonde IP/UDP dans le trafic en direct entre les points du livre SRX Series, et rtt, gigue et perte de paquets entre les points d’installation des sondes sont mesurés pour calculer la qualité du service.
S’il y a une violation détectée pour une application, les mesures de la sonde synthétique sont évaluées afin de déterminer la meilleure liaison qui satisfait au SLA.
Note:À partir de la version 18.3R1 de Junos OS et de la version 15.1X49-D150 de Junos OS, sur tous les équipements SRX Series et instances vSRX pris en charge, afin de détecter si une liaison ou un chemin est en panne par des sondes passives, un minimum de trois demandes de sonde et une perte de paquets de 100 % doivent se produire pendant une période d’échantillonnage pour une session donnée afin de déclencher une violation des SLA.
Note:Lorsque l’équipement fonctionne en mode cluster de châssis, si le nœud secondaire (nœud 1), via lequel le trafic est transféré, est redémarré, plusieurs commutations du trafic applicatif entre les liaisons des nœuds secondaires se produisent. Cela se produit lorsque les liaisons disponibles sur le nœud principal (nœud 0) ont un score sla de chemin de sonde moins actif par rapport aux liaisons de nœud secondaire. Ce comportement se poursuit jusqu’à ce que les résultats des sla de la sonde AppQoE active soient disponibles pour indiquer qu’il y a une perte de paquets de 100 % sur toutes les liaisons sur le nœud secondaire.
Vous pouvez configurer une règle SLA avec des paramètres de sonde actifs et passifs et associer la règle SLA au profil APBR. Le profil APBR inclut également une règle APBR. Les règles sont associées à un ou plusieurs groupes d’applications et le trafic correspondant à la règle est redirigé vers l’instance de routage
AppQoE déclenche les requêtes de sonde sur tous les chemins de sonde de l’application. Des sondes actives et passives surveillent le réseau à la recherche de zones ou de points de défaillance ou d’encombrement.
AppQoE collecte des statistiques de classe de trafic pour les applications apprises à l’aide de sondes actives et passives et prend les mesures suivantes :
Mesure des performances pour les SLA : les métriques en temps réel fournies par les sondes permettent d’évaluer la qualité de service en fonction du SLA d’une application et de déterminer si le chemin de l’application ne répond pas aux exigences des SLA. Autrement dit, s’il y a une violation détectée pour une application, les mesures de la sonde synthétique sont évaluées afin de déterminer la meilleure liaison alternative pour le trafic applicatif qui satisfait au SLA.
Réacheminer le trafic : basculez le trafic applicatif entre les deux liaisons, c’est-à-dire que lorsqu’une liaison présente des problèmes de performances, le trafic est acheminé vers l’autre liaison au cours de la même session.
Si le trafic de l’application peut être atteint via plusieurs liaisons, vous devez configurer tous les chemins accessibles en tant que chemins overlay et attacher les chemins overlay à la règle SLA de l’application.
Commutation du trafic applicatif vers un autre chemin
Vous pouvez activer ou désactiver la commutation du trafic applicatif vers un autre routage (local vers l’équipement) en cas de violation des SLA. Lorsque la commutation de route locale est activée, la commutation du trafic applicatif vers une autre route est activée et la fonctionnalité de surveillance et de reporting SLA est également disponible. Même lorsque l’option de commutation du trafic applicatif vers un autre chemin est désactivée dans la configuration des règles DE SLA, AppQoE résout les violations de SLA--- par exemple, en basculant le trafic applicatif vers un nouveau chemin
Lorsque la commutation de routage local est désactivée, seule la fonctionnalité de surveillance et de reporting des SLA est disponible et la commutation du trafic applicatif vers la route différente en raison d’une violation des SLA est désactivée.
Lorsqu’un trafic applicatif passe à un autre chemin, il y aura un court laps de temps pendant lequel le trafic applicatif ne peut pas être à nouveau transféré vers un autre chemin en cas de violation des SLA. Cette période permet d’éviter le battement du trafic sur les liaisons.
Comprendre les limites de configuration AppQoE
À partir de la version 15.1X49-D160 de Junos OS et de la version 19.1R1 de Junos OS, AppQoE applique la limite de configuration pour les chemins overlay, les profils métriques, les paramètres de sonde et les règles de SLA par profil lorsque vous configurez des règles SLA spécifiques à une application et associe les règles sla à un profil APBR.
Si vous configurez les paramètres au-delà de la limite autorisée, des messages d’erreur s’affichent lorsque vous validez la configuration.
Exemples de messages d’erreur :
Les exemples de messages d’erreur suivants proviennent des équipements SRX4100 et SRX4200. La valeur de la limite de configuration peut ne pas refléter le nombre exact pris en charge ; les chiffres peuvent varier entre les équipements pris en charge
[edit security advance-policy-based-routing]
'sla-rule sla0'
Cannot configure more than 32 sla rules
error: configuration check-out failed
[edit security advance-policy-based-routing]
'overlay-path grep2'
Cannot configure more than 2000 overlay paths
error: configuration check-out failed
[edit security advance-policy-based-routing]
'metrics-profile m0'
Max metrics for this system is 32
error: configuration check-out failed
[edit security advance-policy-based-routing]
'active-probe-params pr0'
Cannot configure more than 64 probe params
error: configuration check-out failed
Sélection des chemins d’application en fonction des préférences et de la priorité des liaisons
L’une des exigences importantes d’un SD-WAN (SD-WAN) est de mesurer la qualité des chemins réseau sous-jacents et, en fonction des résultats, de déterminer les meilleurs chemins à utiliser pour la livraison de chaque paquet.
À partir de La version 18.4R1 de Junos OS et de la version 15.1X49-D160 de Junos OS, vous pouvez configurer la qualité de l’expérience spécifique aux applications (AppQoE) pour sélectionner le chemin d’application en fonction de la priorité de la liaison et du type de liaison lorsque plusieurs chemins qui répondent aux exigences des SLA sont disponibles.
Vous pouvez sélectionner un lien MPLS ou Internet comme chemin préféré, puis attribuer la priorité entre 1 et 255 avec une valeur inférieure indiquant une liaison préférée. Une valeur d’un (1) indique la priorité la plus élevée. S’il y a plusieurs chemins disponibles, le chemin qui a la priorité la plus élevée est sélectionné.
Par exemple, si un chemin MPLS est sélectionné pour le trafic VoIP et que la qualité se produit pendant un appel en raison de la gigue ou de la perte de paquets, les paquets sont envoyés par un autre chemin (Internet) qui répond aux exigences des SLA. Désormais, le trafic applicatif est envoyé par le chemin Internet et si la qualité du chemin Internet est dégradée, le chemin est de nouveau transféré vers MPLS.
Vous pouvez configurer la priorité de liaison et le type de liaison de chaque interface underlay dans une règle de routage avancé basé sur des stratégies (APBR), et les mêmes paramètres sont hérités par l’overlay correspondant. Dans ce cas, une interface underlay est la dernière interface sortante de la topologie de routage pour l’overlay.
Par exemple, dans une infrastructure réseau, si l’underlay est une connexion LTE de quatrième génération (4G), l’interface de numérotation peut être configurée en tant qu’interface underlay pour AppQoE. De même, si l’underlay est une connexion DSL, l’interface PPPoE (Point-to-Point Protocol over Ethernet) correspondante peut être configurée en tant qu’interface underlay pour AppQoE.
À partir de la version 21.2R1 de Junos OS, le mécanisme de sélection des chemins AppQoE est amélioré avec une configuration de balise de liaison personnalisée, un basculement du trafic applicatif vers la liaison de priorité supérieure des balises préférées, un déploiement basé sur des métriques non SLA et des fonctionnalités de préférence d’attributs d’interface overlay.
- Avantages de la priorité et des préférences de chemin d’application
- Mécanisme de sélection des chemins
Avantages de la priorité et des préférences de chemin d’application
-
Permet de choisir le meilleur chemin pour le trafic applicatif.
-
Permet de routage du trafic applicatif sur l’option de connectivité économique tout en s’assurant que les exigences sla (latence et gigue) sont satisfaites.
-
Prend en charge la commutation dynamique des chemins si le chemin d’application sélectionné rencontre une dégradation de la qualité.
Mécanisme de sélection des chemins
Le trafic applicatif est acheminé via des liens distincts en fonction des préférences de liaison comme suit :
-
Le mécanisme de sélection des chemins AppQoE comprend une liste des meilleurs chemins vers une destination spécifique qui répond aux exigences des SLA. Dans cette liste, AppQoE sélectionne un chemin qui correspond à la préférence de liaison configurée par l’utilisateur.
-
S’il existe plusieurs chemins de ce type, le chemin qui a la priorité la plus élevée est sélectionné.
-
S’il n’y a pas de préférence de priorité ou de type de liaison configurée, alors un chemin aléatoire ou le chemin par défaut est sélectionné.
-
Si aucune liaison ne répond aux exigences des SLA n’est disponible, alors le meilleur lien disponible en termes de niveau de service le plus élevé et de préférence de type de liaison, en cas de configuration d’affinité stricte, est sélectionné.
-
Si plusieurs liaisons qui répondent aux exigences des SLA sont disponibles, alors celle qui est la plus prioritaire est sélectionnée.
Messages du journal système pour AppQoE
À partir de la version 19.2R1 de Junos OS, la prise en charge de la journalisation au niveau des applications est disponible pour AppQoE sur les équipements SRX Series. Cette fonctionnalité est introduite pour réduire l’impact sur CSO ou l’équipement de collecte de journaux tout en traitant un grand nombre de messages de journalisation système générés au niveau de la session. L’équipement de sécurité conserve les informations au niveau des sessions et fournit des messages de journalisation système pour le niveau de session. Avec la journalisation au niveau des applications qui remplace la journalisation au niveau des sessions, le surcoût sur l’équipement de sécurité diminue et le débit des journaux AppQoE augmente.
AppQoE envoie les messages de journal système suivants :
APPQOE_SLA_METRIC_VIOLATION : lorsqu’une violation est détectée pour une session et lorsque le chemin d’une session est résolu à la suite du passage à une nouvelle liaison.
APPQOE_BEST_PATH_SELECTED : lorsqu’une session change de chemin pour son trafic de données.
Avec la journalisation au niveau des applications, tous les journaux de niveau session sont pris en charge au niveau de l’application. La fonctionnalité AppQoE qui permet d’envoyer des sondes en temps réel, de mesurer les métriques des SLA, la détection des violations et le commutateur de chemin se poursuit au niveau de la session. Toutefois, dans le cadre de la fonctionnalité de synthèse au niveau de l’application, les sessions de chemin de données informent les mesures sla, les informations de violation et le commutateur de chemin vers la base de données AppQoE. Les informations ainsi reçues du chemin de données sont agrégées au niveau de l’application, puis envoyées sous forme de journaux système à l’équipement de collecte.
Le tableau 1 détaille les nouveaux journaux au niveau des applications pris en charge à partir de la version 19.2R1 de Junos OS.
message du journal système |
Description |
|---|---|
APPQOE_APP_SLA_METRIC_VIOLATION |
|
APPQOE_APP_BEST_PATH_SELECTED |
|
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
|
La journalisation au niveau des applications introduit les fonctionnalités AppQoE suivantes :
La sonde active maintient et utilise uniquement les valeurs RTT et de gigue en temps réel. Pour la perte de paquets, il fait référence à la cause de la session précédente, car la perte de paquets ne peut être calculée qu’à la fin de la fenêtre.
Lors de la validation de configuration, la sonde active définit les valeurs RTT et de gigue à la valeur de 32 bits la plus élevée pour toutes les entrées.
La sonde active conserve les valeurs de la session précédente jusqu’à ce que la valeur en temps réel des mesures soit disponible.
Lorsqu’une perte de paquets de 100 % est observée lors d’un sondage actif, toutes les autres mesures sont définies sur la valeur 32 bits la plus élevée.
Reporting des valeurs non valides pour le RTT et la gigue
Lorsque les données de RTT et de Gigue ne sont pas disponibles, journaliser les messages envoyés avec une valeur non valide de 0xFFFFFFFF et elles peuvent être ignorées par le collecteur de journaux. Le tableau 2 présente quelques scénarios possibles en cas d’envoi d’un RTT et d’une gigue non valides.
Scénario |
Journaux système affectés |
|---|---|
Perte de paquets de 100 % : |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
Perte de paquets supérieure à 0 et inférieure à 100 % : |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
Pas de perte de paquets |
APPQOE_APP_SLA_METRIC_VIOLATION APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
Désactiver la journalisation AppQoE
Par défaut, Le type de journal AppQoE est défini comme journal système. Si vous souhaitez désactiver AppQoE, configurez le type de journal comme désactivé dans la configuration suivante :
Qualité de l’expérience applicative (AppQoE) basée sur les bits DSCP du trafic entrant
Pour surmonter ce scénario, à partir de la version 19.4R1 de Junos OS, AppQoE prend en charge la sélection de chemins basée sur les SLA pour le trafic entrant en fonction de la valeur DSCP. AppQoE sélectionne le meilleur lien possible pour le trafic applicatif en fonction de la valeur de la signature de l’application ou du DSCP ou de la combinaison de l’identification de l’application et de la valeur DSCP. Voir
Prise en charge DSCP dans APBR
Lorsque vous configurez à la fois DSCP et une application dynamique dans une règle APBR, la règle est considérée comme correspondant si le trafic correspond à tous les critères spécifiés dans la règle. Lorsque plusieurs valeurs DSCP sont présentes dans la règle APBR, si un critère correspond, il est considéré comme correspondant.
Un profil APBR peut contenir plusieurs règles, chaque règle avec une variété de conditions de correspondance.
En cas de plusieurs règles APBR dans un profil APBR, la recherche de règles utilise l’ordre de priorité suivant :
Règle avec DSCP + application dynamique
Règle avec application dynamique
Règle avec valeur DSCP
Network Service Orchestrator peut mapper l’application à la valeur DSCP au niveau de la fonction de service externe, et il en est de même au niveau du routeur de passerelle pour mapper le DSCP au profil SLA souhaité.
La figure 1 montre un scénario dans lequel AppQoE sélectionne les chemins en fonction des SLA pour le trafic entrant en fonction de la valeur DSCP et de la signature de l’application dans un cas d’utilisation de routeur de passerelle.
Pour le trafic basé sur la valeur DSCP, AppQoE fonctionne comme suit :
-
Tout le trafic entrant dans le routeur de passerelle à partir du LAN subit l’identification des applications. Tant que le DPI n’identifie pas une application, le système transfère le flux de trafic vers une instance VRF (Virtual Routing and Forwarding) de transfert par défaut. VRF inclut une interface sortante qui lui est associée.
-
L’identification des applications Junos OS identifie les applications et une fois qu’une application est identifiée, ses informations sont enregistrées dans le cache système d’application (ASC).
-
Le système continue de vérifier si les informations sur les applications sont disponibles dans la classification DPI ou ASC.
-
Le mécanisme APBR classe les sessions en fonction des signatures d’applications connues et des valeurs DSCP, et utilise des stratégies pour identifier le meilleur chemin possible pour l’application. La stratégie APBR mappe le trafic applicatif à une VRF spécifique.
-
La présence d’une règle SLA dans la configuration APBR déclenche la fonctionnalité AppQoE ; AppQoE sélectionne le chemin en fonction des SLA pour le trafic en fonction de l’application ou de la valeur DSCP.
Un seul DSCP comprend plusieurs catégories d’applications groupées. Différentes catégories d’applications ont leur modèle de trafic individuel. Dans un tel scénario, la détection d’une violation à l’aide de sondes passives et son application à toutes les sessions peuvent entraîner des faux négatifs et des faux positifs. Pour contourner le problème, évitez d’utiliser l’analyse passive lorsque vous avez configuré une règle SLA basée sur DSCP. Vous pouvez utiliser des sondes actives pour le groupe de chemins de destination vers lequel le trafic est transféré.
Limitations
Les déploiements AppQoE avec des règles basées sur DSCP sur l’équipement est le mode cluster du châssis ont les limites suivantes :
-
Si la correspondance des règles est terminée avant que l’identification de l’application ne soit effectuée et qu’AppQoE déplace la session vers l’autre nœud, alors l’identification de l’application ne se termine pas. Cette condition se produit lorsque la règle basée sur DSCP est configurée.
-
Si vous avez configuré deux règles APBR : 1) avec la valeur DSCP 2) avec DSCP et application dynamique, et que vous avez assigné la même valeur DSCP dans les deux règles, dès la réception du premier paquet, APBR correspond à la règle DSCP. Si le meilleur chemin est identifié sur l’autre nœud, la session est déplacée vers l’autre nœud. Dans ce scénario, les sessions d’application sont mises en correspondance avec la règle DSCP et non avec la règle APP+DSCP.
Stratégies APBR pour AppQoE
À partir de la version 20.1R1 de Junos OS, AppQoE utilise la fonctionnalité de correspondance de règles granulaire fournie par APBR pour fournir la qualité de l’expérience (QoE) basée sur le trafic applicatif.
Dans la version 18.2R1 de Junos OS, l’APBR a pris en charge la configuration des stratégies en définissant des adresses source, des adresses de destination et des applications en tant que conditions de correspondance. Après une correspondance réussie, le profil APBR configuré est appliqué en tant que services d’application pour la session. Dans la version 20.1R1 de Junos OS, AppQoE exploite l’amélioration APBR et sélectionne la meilleure liaison possible pour le trafic applicatif envoyé par APBR pour répondre aux exigences de performances spécifiées dans les SLA.
Par exemple, vous souhaitez transférer le trafic Telnet et HTTPS arrivant dans la zone de confiance vers un équipement ou une interface spécifique via un lien disponible. Lorsque le trafic arrive dans la zone de confiance, l’APBR fait correspondre le trafic avec l’adresse source, l’adresse de destination et les applications définies dans les stratégies APBR. Si le trafic correspond à la stratégie, les profils APBR correspondants sont appliqués.
APBR utilise les détails de l’application pour rechercher une règle de correspondance dans le profil. Si une règle correspondante est trouvée, le trafic est redirigé vers l’instance de routage spécifiée, telle que définie dans la règle.
Multi-homing AppQoE avec déploiement actif-actif
À partir de la version 20.2R1 de Junos OS, AppQoE est amélioré pour prendre en charge le multi-homing avec un déploiement actif-actif. Auparavant, AppQoE soutenait le multihébergement avec le déploiement de réserve active.
Dans le déploiement actif-actif, l’équipement en étoile se connecte à plusieurs équipements hub. Le trafic applicatif peut transiter par n’importe quel équipement hub si la liaison vers l’équipement hub répond aux exigences des SLA. Le trafic applicatif peut basculer de manière transparente entre les équipements du hub en cas de violation des SLA ou si l’équipement du hub actif ne répond pas
La figure 1 montre une topologie de maillage. Dans cette topologie, un point final est accessible via plusieurs nœuds.
maillage
Pour activer le multihébergement en mode actif-actif, vous devez configurer le multichemin BGP pour permettre à l’équipement de sélectionner plusieurs chemins BGP à coût égal pour atteindre une destination donnée.
Lorsque vous activez le chemin multichemin BGP, l’équipement sélectionne plusieurs chemins BGP à coût égal pour atteindre une destination donnée, et tous ces chemins sont installés dans la table de transfert. AppQoE termine la recherche de route et obtient les détails du routage du saut suivant ainsi que les liaisons overlay correspondantes. AppQoE obtient la propriété overlay-link du groupe de chemins de destination configuré.
En fonction des sla requis et des préférences de liaison de l’application, AppQoE détermine la meilleure liaison parmi toutes les liaisons de ce groupe de chemins de destination. En cas de violation des SLA, en fonction du score sla et des préférences de liaison, AppQoE sélectionne d’autres liaisons dans tous les groupes de chemins de destination configurés si le point de terminaison est accessible via ces liaisons.
Pour plus d’informations sur la configuration multichemin BGP, consultez exemples : configuration de BGP Multipath.
Limitation
Dans certains scénarios, lorsque l’ID du saut suivant pour le routage change, les sessions existantes restent sur la liaison violée par les SLA, même si une autre liaison qui répond aux exigences des SLA est disponible. Toutefois, les nouvelles sessions ne sont pas impactées dans ce cas et elles sont acheminées via les liaisons qui répondent aux exigences des SLA.
Prise en charge des applications SaaS
À partir de la version 20.4R1 de Junos OS, nous avons étendu la prise en charge de la qualité de l’expérience applicative (AppQoE) pour les applications SaaS (Software as a Service).
AppQoE effectue des mesures d’accord de niveau de service (SLA) sur les liaisons WAN disponibles telles que underlay, GRE, IPsec ou MPLS over GRE. Il envoie ensuite les données des applications SaaS sur la liaison la plus conforme aux SLA pour fournir un service cohérent.
Prise en charge du trafic IPv6
-
À partir de la version 21.3R1 de Junos OS, vous pouvez utiliser des adresses IPv6 dans les configurations AppQoE. L’assistance comprend :
- Adresse IPv6 dans la configuration du chemin overlay
- Sessions d’analyse actives utilisant des adresses IPv6 comme adresse source et destination.
- Trafic IPv4 et IPv6 côté client
- Double empilage des IPv4 et IPv6 côté LAN
- Adresse IPv6 côté LAN pour l’analyse SaaS (software as a service).
Pour l’analyse SaaS, assurez-vous de configurer les adresses IPv4 et IPv6 pour l’interface entrante pour l’interopérabilité IPv4 et IPv6.
- À partir de la version 21.4R1 de Junos OS, vous pouvez utiliser un double empilage des IPv4 et IPv6 pour les réseaux overlay et underlay dans une configuration AppQoE.