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-t-elle les performances applicatives ?
- basculement du trafic applicatif vers un autre chemin
Introduction à la qualité de l’expérience applicative
La croissance inéluctable du cloud computing, de la mobilité et des applications Web exige que le réseau identifie et contrôle le trafic au niveau de l’application, et gère chaque type d’application séparément afin d’offrir 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 emploie) les fonctionnalités de deux services de sécurité des applications : l’identification des applications (AppID) et le routage avancé basé sur des stratégies (APBR). Il utilise AppID pour identifier des applications spécifiques dans votre réseau et le routage avancé basé sur des stratégies (APBR) pour spécifier un chemin pour un certain trafic en associant des profils SLA à une instance de routage sur laquelle le trafic de l’application est envoyé conformément aux règles APBR.
L’une des exigences importantes d’un WAN défini par logiciel (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 le meilleur lien possible pour le trafic de ces applications afin de répondre aux exigences de performance spécifiées dans le SLA (accord de niveau de service).
La présence d’une règle SLA dans la configuration de l’APBR déclenche la fonctionnalité AppQoE. Si aucun profil SLA n’est disponible, 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 d’informations, consultez Présentation de la qualité de l’expérience applicative et Configurer et surveiller la qualité de l’expérience applicative.
Options de configuration prises en charge
AppQoE est pris en charge sur les topologies en étoile et de maillage complet dans les déploiements SD-WAN.
Vous pouvez configurer une AppQoE entre deux points de terminaison de pare-feu Junos OS (sans réserve) et les deux pare-feu doivent avoir la même version de l’image Junos OS.
Avantages de la qualité de l’expérience applicative
-
Permet une QoE rentable en surveillant en temps réel le trafic applicatif afin de fournir un niveau de service constant et prévisible.
-
Augmente la rétention et la satisfaction des clients en fournissant un SLA garanti pour l’acheminement d’un certain trafic (comme le trafic vidéo). AppQoE garantit que le trafic approuvé reçoit la priorité et la bande passante appropriées pour garantir la meilleure qualité d’expérience à l’utilisateur.
Limitations
La mise en œuvre 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, pondération et métriques configurées. Tous les itinéraires doivent être ajoutés en tant que chemins ECMP pour la destination et doivent également faire partie de la même table de transfert.
-
Service SLA AppQoE uniquement entre deux points de terminaison d’appareils de sécurité (sans blocage) sont 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é au trafic inverse.
-
AppQoE n’influe pas sur la modification de la destination d’une session.
-
AppQoE ne prend pas en charge l’encapsulation de sonde IPv6/UDP, GRES, les clusters de châssis (ISSU, haute disponibilité, haute disponibilité double CPE, haute disponibilité en mode Z) et les systèmes logiques.
-
AppQoE ne prend pas en charge la sélection de chemin préféré et le routage et le transfert virtuels de transit (VRF) ne sont pas pris en charge.
-
AppQoE ne prend pas en charge le sondage passif sur les paquets de données IPv6.
-
Un filtre de pare-feu d’entrée est requis au niveau des interfaces non-WAN pour rejeter les paquets UDP avec le port de destination UDP 36000.
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 le meilleur lien possible pour ce trafic applicatif afin de répondre aux exigences de performance spécifiées dans le SLA (accord de niveau de service).
- Identification d’applications ou de groupes d’applications
- Spécification du chemin d’accès pour les applications ou les groupes d’applications
- Sélection du chemin de trafic de l’application
Identification d’applications ou de groupes d’applications
L’identification des applications ou des groupes d’applications suit les étapes suivantes :
-
L’identification des applications par Junos OS permet d’identifier les applications et, une fois l’application identifiée, ses informations sont enregistrées dans le cache du système de l’application (ASC).
-
L’APBR évalue les paquets afin de déterminer si la session est candidate pour le routage basé sur les applications (routage avancé basé sur les stratégies). S’il s’agit du premier paquet de la nouvelle session et que le trafic n’est pas marqué pour le routage basé sur l’application, il subit un traitement normal (route non-APBR) jusqu’à la destination.
-
Si la session a besoin d’un routage basé sur l’application, 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 traité pour 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 d’itinéraire.
-
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 les mesures de 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 est introuvable dans ASC, l’APBR demande une inspection approfondie du flux. En d’autres termes, le package de signature d’application est installé et l’identification de l’application pour la session est activée, de sorte que l’ASC puisse être renseigné pour être utilisé par les sessions suivantes pour le traitement APBR (voir l’étape 2).
-
Spécification du chemin d’accès pour les applications ou les groupes d’applications
Les étapes suivantes résument la manière dont AppQoE spécifie un chemin pour le trafic de l’application en fonction des règles SLA.
-
APBR utilise les détails de l’application pour rechercher une règle de correspondance dans le profil APBR (profil d’application). Le trafic correspondant aux applications et aux groupes d’applications est transféré vers la route statique et l’adresse de saut suivant, comme spécifié dans l’instance de routage.
-
Une règle de SLA attachée au profil APBR spécifie les paramètres nécessaires pour mesurer le SLA et identifier si une violation de SLA s’est produite ou non.
-
Le trafic des applications est affecté à un lien overlay particulier en fonction des métriques SLA de ce lien overlay, mesurées à l’aide d’un sondage actif.
-
Le non-respect des SLA est déterminé par un sondage passif du trafic de l’application active/du groupe d’applications. L’algorithme de sélection du chemin détermine la meilleure liaison chemin/superposition pour l’application/le groupe d’applications.
Sélection du chemin de trafic de l’application
Les étapes suivantes sont nécessaires pour acheminer le trafic de données de la source vers 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), 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), un chemin aléatoire ou le chemin par défaut est choisi. Ce chemin se poursuit pendant toute la session. Par la suite, 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 initialement connue, AppQoE sélectionne le meilleur chemin pour le trafic de l’application.
Lorsqu’une nouvelle application est détectée, le mécanisme de sélection du chemin tente de trouver un chemin qui satisfait toutes les mesures SLA. Si aucun chemin de ce type n’existe, le meilleur chemin suivant (en fonction du nombre de mesures satisfaites) est utilisé. S’il existe plusieurs chemins qui satisfont les mesures, un chemin aléatoire parmi les chemins disponibles est sélectionné. La violation du SLA est détectée lorsqu’une mesure n’est pas respectée ou qu’aucune d’entre elles ne répond à l’exigence, en fonction de la configuration du profil.
Comment la qualité de l’expérience applicative mesure-t-elle les performances applicatives ?
Les performances des applications sont déterminées par les indicateurs suivants :
-
Latence : durée physique nécessaire pour que les médias se déplacent en fonction de la longueur et de la distance à parcourir
-
RTT : temps d’aller-retour nécessaire pour se rendre de la source à la destination et vice versa.
-
Perte de paquets : la perte de paquets reflète le nombre de paquets perdus pour 100 paquets envoyés par un hôte.
-
Gigue : la gigue correspond à la différence de latence d’un paquet à l’autre. La gigue d’entrée, la gigue de sortie et la gigue bidirectionnelle peuvent être spécifiées pour évaluer les performances de la liaison.
AppQoE surveille le RTT, la gigue et la perte de paquets sur chaque liaison et, en fonction du score, redirige de manière transparente les applications vers l’autre chemin si les performances de la liaison principale sont inférieures aux niveaux acceptables spécifiés par le SLA. Les performances des applications sont mesurées et surveillées à l’aide de sondes actives et passives afin de détecter les violations des SLA et de sélectionner un autre chemin pour cette application particulière.
AppQoE recueille des données en temps réel en surveillant en permanence le trafic des applications et en identifiant les problèmes de réseau ou d’équipement en :
-
Surveillance des performances sur toutes les liaisons de superposition configurées.
-
Utilisation de sondes passives (en ligne avec le chemin de données de l’application) et de sondes actives (sondes synthétiques pour une application spécifique) pour surveiller les performances du trafic d’une application ou d’un groupe d’applications.
-
Envoi de toutes les mesures 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 mesure de performance spécifique et modification dynamique du chemin d’accès au trafic de l’application en cas de violation du SLA.
-
Prise en charge d’une configuration métrique SLA flexible pour une application ou un groupe d’applications donné.
AppQoE mesure le SLA de l’application sur plusieurs liaisons WAN et mappe le trafic de l’application vers un chemin parmi les liens disponibles, c’est-à-dire vers le chemin qui répond le mieux aux exigences de SLA.
Mesure des performances des applications à l’aide de sondes actives et passives
Les mesures de sonde actives et passives 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 fournir une mesure de bout en bout des performances du réseau.
Dans le cadre du sondage actif, des paquets personnalisés sont envoyés entre les points Spoke et le concentrateur sur toutes les routes multiples, et le RTT, la latence, la gigue et la perte de paquets sont mesurés entre les points de sonde installés. Les sondes actives sont envoyées périodiquement sur tous les liens actifs et passifs. Un nombre configuré d’échantillons est collecté et une moyenne mobile pour la trajectoire de sonde de chacune de ces applications est mesurée. Si une violation est détectée pour un trafic applicatif, les métriques de la sonde sont évaluées afin de déterminer la meilleure liaison qui satisfait au 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.
Le palpage passif surveille les liaisons pour détecter tout non-respect des SLA sur le trafic de données en direct. Dans une sonde passive, les paquets de données sont encapsulés dans un en-tête de sonde IP/UDP dans le trafic en temps réel entre les points d’extrémité de l’appareil. Le palpage mesure le RTT, la gigue et la perte de paquets entre les points d’installation des sondes pour calculer la qualité de service.
Si une violation est détectée pour une application, les métriques de la sonde synthétique sont évaluées afin de déterminer la meilleure liaison qui satisfait au SLA.
Note:Afin de détecter si une liaison ou un chemin est interrompu par des sondes passives, au moins trois requêtes de sonde et une perte de paquets de 100 % doivent se produire au cours d’une période d’échantillonnage pour une session donnée afin de déclencher une violation du SLA.
Note:Lorsque l’équipement fonctionne en mode cluster de châssis, si le noeud secondaire (noeud 1) par lequel le trafic est transféré est redémarré, plusieurs commutations du trafic applicatif entre les liens via les liaisons de noeud secondaire se produisent. Cela se produit lorsque les liens disponibles sur le noeud principal (noeud 0) ont un score de chemin SLA de sonde actif inférieur à celui des liens de noeud secondaire. Ce comportement se poursuit jusqu’à ce que les résultats du score de chemin SLA de la sonde active AppQoE soient disponibles pour indiquer qu’il y a une perte de paquets de 100 % sur toutes les liaisons du 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 à une ou plusieurs applications ou groupes d’applications et le trafic correspondant à la règle est redirigé vers l’instance de routage
AppQoE déclenche les demandes de sonde vers 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 de congestion.
AppQoE collecte des statistiques sur les classes de trafic des applications apprises à l’aide de sondes actives et passives et prend les mesures suivantes :
-
Mesurer les performances pour le SLA : les mesures en temps réel fournies par les sondes sont utilisées pour évaluer la qualité de service en fonction du SLA d’une application et déterminer si le chemin de l’application ne répond pas aux exigences du SLA. En d’autres termes, si une violation est détectée pour une application, les métriques de la sonde synthétique sont évaluées afin de déterminer le meilleur lien alternatif pour le trafic de l’application qui satisfait au SLA.
-
Réacheminer le trafic : bascule le trafic de l’application entre les deux liaisons, autrement dit, 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 est accessible via plusieurs liens, vous devez configurer tous les chemins accessibles en tant que chemins de superposition et les associer à la règle de SLA de l’application.
basculement du trafic applicatif vers un autre chemin
Vous pouvez activer ou désactiver le basculement du trafic de l’application vers un autre itinéraire (local à l’appareil) en cas de violation du SLA. Lorsque la commutation de route locale est activée, le basculement du trafic de l’application vers une autre route est activé et la fonctionnalité de surveillance et de création de rapports SLA est également disponible. Même lorsque l’option permettant de basculer le trafic de l’application vers un autre chemin est désactivée dans la configuration de la règle SLA, AppQoE résout les violations de SLA, par exemple en basculant le trafic de l’application vers un nouveau chemin.
Lorsque la commutation de route locale est désactivée, seule la fonctionnalité de surveillance et de création de rapports SLA est disponible et le basculement du trafic de l’application vers un autre itinéraire en raison d’une violation de SLA est désactivé.
Lorsqu’un trafic applicatif bascule vers un autre chemin, il y a une courte période pendant laquelle le trafic applicatif ne peut plus être basculé vers un autre chemin en cas de non-respect du SLA. Cette période permet d’éviter les fluctuations du trafic sur les liaisons.
Comprendre les limites de configuration d’AppQoE
AppQoE applique la limite de configuration pour les chemins de superposition, les profils de métriques, les paramètres de sonde et les règles 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 :
La valeur de la limite de configuration peut ne pas refléter le nombre exact de personnes prises en charge. Les chiffres peuvent différer selon les appareils 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 WAN défini par logiciel (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.
Vous pouvez configurer la qualité d’expérience spécifique à l’application (AppQoE) pour sélectionner le chemin d’application en fonction de la priorité et du type de lien lorsque plusieurs chemins répondant aux exigences du SLA sont disponibles.
Vous pouvez sélectionner un lien MPLS ou Internet comme chemin préféré, attribuer une priorité comprise entre 1 et 255, une valeur inférieure indiquant un lien préféré. La valeur un (1) indique la priorité la plus élevée. Lorsque plusieurs chemins sont disponibles, celui qui a la priorité la plus élevée est choisi.
Par exemple, si un chemin MPLS est sélectionné pour le trafic VoIP et qu’une dégradation de la qualité se produit au cours d’un appel en raison d’une gigue ou d’une perte de paquets, les paquets sont envoyés via un autre chemin (Internet) qui répond aux exigences de SLA. Désormais, le trafic des applications est envoyé via le chemin Internet et, si la qualité du chemin Internet est dégradée, le chemin est rebasculé vers MPLS.
Vous pouvez configurer la priorité de liaison et le type de liaison de chaque interface de couche inférieure dans une règle de routage basé sur des stratégies avancées (APBR), et les mêmes paramètres sont hérités par la superposition correspondante. Dans ce cas, une interface underlay est l’interface sortante finale dans 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.
Le mécanisme de sélection du chemin AppQoE est amélioré avec la configuration de balises de lien personnalisées, le basculement du trafic applicatif vers le lien de priorité supérieure des balises préférées, le déploiement basé sur des métriques non SLA et des fonctionnalités de préférence d’attribut d’interface superposées.
- Avantages de la préférence et de la priorité des chemins d’application
- Mécanisme de sélection de chemin
Avantages de la préférence et de la priorité des chemins d’application
-
Permet de sélectionner le meilleur chemin pour le trafic applicatif en toute flexibilité.
-
Permet d’acheminer le trafic applicatif via l’option de connectivité économique tout en s’assurant que les exigences de SLA (latence et gigue) sont respectées.
-
Prend en charge le changement de chemin dynamique si le chemin d’application sélectionné subit une dégradation de la qualité.
Mécanisme de sélection de chemin
Le trafic des applications est acheminé via des liens distincts en fonction de la préférence de lien, comme suit :
-
Le mécanisme de sélection de chemin AppQoE inclut une liste des meilleurs chemins vers une destination spécifique qui répond aux exigences du SLA. Dans cette liste, AppQoE sélectionne un chemin qui correspond à la préférence de liaison configurée par l’utilisateur.
-
Si plusieurs chemins de ce type sont disponibles, le chemin qui a la priorité la plus élevée parmi tous les chemins est sélectionné.
-
Si aucune priorité ni préférence de type de lien n’est configurée, un chemin aléatoire ou le chemin par défaut est sélectionné.
-
Si aucune liaison répondant aux exigences du SLA n’est disponible, le meilleur lien disponible en termes de score de SLA le plus élevé et de préférence de type de lien, dans le cas où une affinité stricte est configurée, est sélectionné.
-
Si plusieurs liaisons répondant aux exigences du SLA sont disponibles, celle qui a la priorité la plus élevée est sélectionnée.
Pour obtenir un exemple de configuration, reportez-vous à la section Configurer la liaison WAN avec la sauvegarde LTE en mode actif/actif.
Messages du journal système pour AppQoE
La journalisation au niveau de l’application est introduite pour réduire l’impact sur CSO ou le périphérique de collecte des journaux lors du traitement d’un grand nombre de messages de journal système générés au niveau de la session. L’équipement de sécurité gère les informations au niveau de la session et fournit des messages de journal système pour chaque session. Lorsque la journalisation au niveau des applications remplace la journalisation au niveau des sessions, la surcharge des équipements 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’accès à une session est résolu suite au déplacement vers un nouveau lien.
-
APPQOE_BEST_PATH_SELECTED : lorsqu’une session change de chemin pour son trafic de données.
Avec la journalisation au niveau de l’application, tous les journaux au niveau de la 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 SLA, de détecter les violations et de changer 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 notifient les métriques SLA, les informations sur les violations et le commutateur de chemin vers la base de données AppQoE. Les informations ainsi reçues de datapath sont agrégées au niveau de l’application, puis envoyées sous forme de journaux système au périphérique collecteur.
Le Tableau 1 détaille les nouveaux journaux pris en charge au niveau de l’application.
| 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 de l’application introduit les modifications suivantes des fonctionnalités AppQoE :
-
La sonde active gère et utilise uniquement les valeurs RTT et gigue en temps réel. Dans le cas d’une perte de paquets, il s’agit de 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 la configuration, la sonde active définit les valeurs RTT et de gigue sur la valeur 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 qu’une valeur en temps réel appropriée des mesures soit disponible.
-
Lorsqu’une perte de paquets de 100 % est constatée lors du sondage actif, toutes les autres mesures sont définies sur la valeur 32 bits la plus élevée.
Rapport des valeurs non valides pour le RTT et la gigue
Lorsque les données RTT et Jitter ne sont pas disponibles, consignez les messages envoyés avec une valeur non valide de 0xFFFFFFFF et celle-ci peut être ignorée par le collecteur de journaux. Le Tableau 2 présente quelques scénarios possibles lorsque le RTT et la Gigue non valides sont envoyés.
| 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
AppQoE prend en charge la sélection de chemin basée sur SLA pour le trafic entrant en fonction de la valeur DSCP. AppQoE sélectionne le meilleur lien possible pour le trafic de l’application en fonction de la signature de l’application ou de la valeur DSCP, ou d’une combinaison de l’identification de l’application et de la valeur DSCP.
Prise en charge de 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 correspondance 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, chacune d’entre elles étant assortie de diverses 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 d’une fonction de service externe, et celle-ci est provisionnée au niveau du routeur de passerelle pour mapper le DSCP au profil de SLA souhaité.
La figure 1 montre un scénario dans lequel AppQoE sélectionne le chemin du trafic entrant en fonction d’un SLA 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 réseau local est identifié par l’application. Tant que la DPI n’a pas identifié une application, le système transfère le flux de trafic vers une instance VRF (Forwarding, Forwarding) virtuelle de routage et de transfert par défaut. Le VRF inclut une interface sortante associée.
-
L’identification des applications par Junos OS permet d’identifier les applications et, une fois l’application identifiée, ses informations sont enregistrées dans le cache du système de l’application (ASC).
-
Le système continue de vérifier si des informations sur l’application sont disponibles à partir de la classification DPI ou de l’ASC.
-
Le mécanisme APBR classe les sessions en fonction des signatures d’applications connues et des valeurs DSCP, et utilise la stratégie pour identifier le meilleur chemin possible pour l’application. La stratégie APBR mappe le trafic de l’application à un VRF spécifique.
-
La présence d’une règle SLA dans la configuration de l’APBR déclenche la fonctionnalité AppQoE. AppQoE sélectionne le chemin du trafic en fonction d’un SLA en fonction de l’application ou de la valeur DSCP.
Un seul DSCP inclut plusieurs catégories d’applications. Les différentes catégories d’applications ont leur propre modèle de trafic. Dans un tel scénario, la détection de la violation à l’aide de sondes passives et son application à toutes les sessions peuvent entraîner des faux négatifs et faux positifs. Pour contourner ce problème, évitez d’utiliser le sondage passif 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’appareil en mode cluster de châssis présentent les limitations suivantes :
-
Si la correspondance de la règle 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, 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 l’application dynamique, et que vous avez affecté la même valeur DSCP dans les deux règles, à 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 comparées à la règle DSCP et non à la règle APP+DSCP.
Stratégies APBR pour AppQoE
AppQoE tire parti de l’amélioration APBR et sélectionne le meilleur lien possible pour le trafic applicatif tel qu’envoyé par APBR afin de répondre aux exigences de performances spécifiées dans le SLA. AppQoE utilise la fonctionnalité de correspondance de règles granulaire fournie par APBR pour fournir la qualité d’expérience (QoE) en fonction du trafic de l’application.
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 le meilleur lien disponible. Lorsque le trafic arrive dans la zone de confiance, l’APBR fait correspondre le trafic avec les critères correspondants : 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.
Multihébergement AppQoE avec déploiement actif-actif
AppQoE a été amélioré pour prendre en charge le multihébergement avec déploiement actif-actif. Auparavant, AppQoE prenait en charge le multihébergement avec déploiement de secours actif.
Dans le cadre d’un déploiement actif-actif, le périphérique spoke se connecte à plusieurs équipements du concentrateur. Le trafic applicatif peut transiter par n’importe quel équipement du hub si la liaison vers l’équipement du hub répond aux exigences de SLA. Le trafic applicatif peut basculer de manière transparente entre les équipements du hub en cas de non-respect des SLA ou si l’équipement du hub actif ne répond pas
La figure 1 illustre une topologie de maillage. Dans cette topologie, un point de terminaison est accessible via plusieurs nœuds.
de 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 de coût égal afin d’atteindre une destination donnée.
Lorsque vous activez BGP multipath, l’équipement sélectionne plusieurs chemins BGP de 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 récupère les détails de la route du saut suivant, ainsi que les liens de superposition correspondants. AppQoE obtient la propriété overlay-link à partir du groupe de chemins de destination configuré.
En fonction des exigences de SLA de l’application et des préférences de liaison, AppQoE détermine la meilleure liaison parmi toutes les liaisons de ce groupe de chemins de destination. En cas de non-respect du SLA, en fonction du score de SLA et des préférences de liaison, AppQoE sélectionne d’autres liens sur tous les groupes de chemins de destination configurés si le point de terminaison est accessible via ces liens.
Pour plus d’informations sur la configuration des chemins multiples BGP, reportez-vous à la section Exemples : configuration des chemins multiples BGP.
Limitation
Dans certains scénarios, lorsque l’ID de saut suivant de la route change, les sessions existantes restent sur le lien violant le SLA, même si un autre lien répondant aux exigences de SLA est disponible. Toutefois, les nouvelles sessions ne sont pas affectées dans ce cas et elles sont acheminées via les liens qui répondent aux exigences SLA.
Prise en charge des applications SaaS
Nous avons étendu la prise en charge de la qualité de l’expérience applicative (AppQoE) aux applications SaaS (Software as a Service).
AppQoE mesure les accords de niveau de service (SLA) sur les liaisons WAN disponibles, telles que l’underlay, GRE, IPsec ou MPLS over GRE. Il envoie ensuite les données de l’application SaaS sur le lien le plus conforme au SLA pour fournir un service cohérent.
Prise en charge du trafic IPv6
-
Vous pouvez utiliser des adresses IPv6 dans les configurations AppQoE. L’accompagnement comprend :
- Adresse IPv6 dans la configuration du chemin d’accès à la superposition
- Sessions de sondage actives utilisant les adresses IPv6 comme adresses source et de destination.
- Trafic IPv4 et IPv6 côté client
- Double empilage d’IPv4 et d’IPv6 côté LAN
- Adresse IPv6 côté LAN pour le palpage SaaS (software as a service).
Pour le test SaaS, assurez-vous de configurer les adresses IPv4 et IPv6 pour l’interface entrante afin de garantir l’interopérabilité IPv4 et IPv6.
Informations supplémentaires sur la plate-forme
Utilisez l’explorateur de fonctionnalités AppQoE pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour examiner le comportement spécifique à votre plate-forme :
| Plateforme |
Différence |
|---|---|
| SRX Series |
La configuration des périphériques spoke est recommandée pour les SRX300, SRX320, SRX345, SRX340, SRX550M et vSRX. |
| SRX Series |
Il est recommandé de configurer le concentrateur pour les SRX1500, les SRX4100 et les SRX4200. |
| SRX Series |
Sur SRX4600, AppQoE ne prend pas en charge CoS pour GRE, les détails de la sonde passive peuvent ne pas être disponibles pour les sessions de courte durée et la synchronisation de l’état de session peut échouer sur le nœud secondaire en mode Z Traitement du trafic en mode cluster de châssis. |
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.