3e partie : Configuration de la qualité de l’expérience applicative avec le SD-WAN

Aperçu

Dans cette section, vous configurez l’expérience de qualité des applications (AppQoE) sur le SRX. AppQoE améliore l’expérience utilisateur au niveau de l’application. Les sondes de performance surveillent en permanence les paramètres de qualité de service et la conformité des accords de niveau de service (SLA) du trafic applicatif. Résultat : le trafic des applications utilise toujours le lien le plus conforme aux SLA disponibles.

Examinons les applications répertoriées dans le tableau 1. Par exemple, les applications Office365, Salesforce et Zoom sont considérées comme essentielles pour l’entreprise. Toutes les applications critiques doivent être acheminées via la liaison WAN privée lorsqu’elle répond aux exigences SLA de l’application. Les applications critiques utilisent également la liaison LTE lorsque toutes les autres liaisons sont indisponibles.

Les applications restantes utilisent la liaison d’accès Internet haut débit comme lien principal. Seules les applications stratégiques peuvent utiliser la liaison de sauvegarde LTE, et les applications non critiques sont inaccessibles lorsque seule la connexion LTE est disponible.

Tableau 1 : Applications typiques utilisées dans les filiales
Application	Lien principal	Lien secondaire	Votre entreprise est-elle essentielle ?
Office365	WAN privé	Internet haut débit	Oui
Salesforce	WAN privé	Internet haut débit	Oui
Zoom	WAN privé	Internet haut débit	Oui
Mou	Internet haut débit	WAN privé	Non
Gotomeeting	Internet haut débit	WAN privé	Non
Dropbox	Internet haut débit	WAN privé	Non
Skype	Internet haut débit	WAN privé	Non
Youtube	Internet haut débit	WAN privé	Non

Note:

Vous configurez AppQoE pour une application critique et une application non critique pour que l’exemple reste concentré. Vous pouvez facilement adapter la configuration pour prendre en charge des applications supplémentaires en spécifiant le type de sonde souhaité et le nom de domaine ou l’adresse IP cible souhaités.

Procédure étape par étape

Créez des sondes de surveillance des performances temporelles pour Office 365. Office 365 est une application critique selon le tableau 1. Nous avons installé une sonde pour tester la connectivité à l’adresse IP utilisée par Office365, en particulier 40.97.223.114. La sonde est configurée pour envoyer 5 sondes basées sur le ping, distantes de 6 secondes sur la liaison WAN privée. Nous configurons également les seuils qui ne doivent pas être violés, tels que la perte de 5 sondes successives, ou une sonde temps de transit aller-retour (RTT) supérieure à 3 0000 microsecondes. L’adresse IP de la passerelle sur l’interface ge-0/0/3 est 192.168.220.1.
Pointe:
Vous pouvez saisir la cible de sonde sous la forme d’une adresse IP ou sous la forme d’un nom de domaine. Si un nom est spécifié, le logiciel Junos le résout automatiquement à l’adresse IP correspondante dans la configuration. Cet exemple montre les sondes basées sur ICMP. D’autres types de sondes existent, par exemple un http-get. Tous les sites ne répondent pas aux messages ping (echo request) ICMP. Assurez-vous d’utiliser un type de sonde pris en charge par le fournisseur d’applications.

Créez la deuxième sonde pour la même application afin de sonder la liaison secondaire à l’aide de l’interface secondaire. L’adresse IP de la passerelle par défaut sur la liaison Internet haut débit est 172.16.1.1.

De la même manière, vous créez deux sondes pour l’application Skype. Selon le tableau 1, Skype n’est pas une application stratégique pour l’entreprise. Nous exigeons une garantie de niveau de service plus rigoureuse pour cette application en temps réel (mais non critique). En particulier, vous configurez un intervalle de sonde plus court de 1 seconde et un seuil RTT plus court de 6 0000 microsecondes.

Note:

Nous avons configuré les sondes primaires et secondaires sur l’interface en fonction de l’importance de l’application. L’interface et l’adresse IP de l’sonde principale pour les applications non critiques (Skype) sont différentes de celles de l’application critique (Office365).

Créez une instance de routage pour chaque application. Nous configurons le routage d’une application pour le lien principal avec une valeur de préférence inférieure à la liaison de sauvegarde. Les routes avec une valeur de préférence inférieure préfèrent les routes à valeur supérieure. Vous n’incluez l’interface de sauvegarde LTE que pour les applications stratégiques de l’entreprise.

L’instance de routage d’Office365 définit une valeur de préférence de routage de 10 pour la passerelle WAN privée (route la plus privilégiée). Valeur de préférence de 20 pour la liaison Internet haut débit (routage préféré suivant). Et une valeur de préférence de 30 pour la liaison de sauvegarde LTE (la route la moins privilégiée).
Configurez les instances de routage de l’application Slack dans un modèle similaire. Cette application non critique n’inclut pas l’interface LTE dans l’instance de routage. Omettre l’interface LTE est ce qui empêche les applications non critiques d’utiliser la liaison de sauvegarde LTE. Notez également que les préférences de routage statiques de cette application utilisent l’Internet haut débit comme lien principal.
Configurez les stratégies de surveillance IP pour les applications. L’objectif des stratégies est de modifier dynamiquement la métrique des routes par défaut dans les instances de routage. Les stratégies fonctionnent par sonde.

Dans cette étape, nous créons la stratégie de surveillance IP pour l’application Office365. Pour Office365, nous configurons deux sondes et créons deux stratégies, une pour chaque sonde. Lorsque l’sonde détecte que le trafic de l’application a enfreint le seuil configuré sur une liaison, la stratégie modifie la préférence des routes. La stratégie réduit la mesure pour le deuxième meilleur lien vers 2. Cette modification dirige le trafic de l’instance de routage vers la liaison de secours.

Par exemple, lorsque l’sonde identifie que la liaison principale d’Office365, la liaison WAN privée, ne répond pas aux exigences de RTT et de perte, la stratégie remplace la métrique de la passerelle pour la liaison Internet haut débit (routage préféré suivant) par une valeur de 2.

Configurez la stratégie de surveillance IP pour l’analyse secondaire pour Office365.

Note:

L’adresse du saut suivant est l’adresse IP de la liaison WAN privée principale.

Configurez la stratégie de surveillance IP pour l’application Slack.

Configurez un profil de routage avancé basé sur des stratégies (APBR). Votre profil APBR correspond aux deux applications utilisées dans cet exemple. Le profil redirige le trafic correspondant vers leur instance de routage respective. Le profil utilise des règles, chacune couvrant une application et une instance de routage. Pour cet exemple, nous configurons une règle nommée office365_rule pour qu’elle corresponde à l’ensemble du trafic de l’application nommée « junos:OFFICE365-CREATE-CONVERSATION » et redirigeons le trafic vers l’instance de routage nommée office365_RInstance. L’application Slack est distribuée de la même manière.

Note:
APBR nécessite une licence appid-sig. Sans la licence, vous obtiendrez une erreur de validation. Pour plus de détails, reportez-vous à la section Conditions requises.
Note:
Pour maintenir la continuité des applications et ne pas affecter les utilisateurs, nous souhaitons interdire les modifications de chemin de mi-session pour les sessions établies. Vous définissez le max-route-change paramètre sur 0 pour empêcher les modifications apportées aux sessions établies.

Pointe:
Le logiciel Junos prend en charge une liste étendue d’applications reconnues dynamiquement. L’identification des applications fournit une visibilité sur les applications sur votre réseau, vous montrant le fonctionnement de l’application, ses caractéristiques comportementales et son risque relatif. App ID utilise de nombreux mécanismes pour détecter les applications sur votre réseau. App ID fonctionne indépendamment du port, du protocole, du chiffrement (TLS/SSL ou SSH) ou d’autres tactiques évasives. Pour plus d’informations, voir Identification des applications.
Configurez un groupe indépendant du protocole des tables de routage. Cette configuration copie les routes d’interface des différentes instances de routage d’application. Ces copies de cette route permettent à une instance donnée d’utiliser le WAN privé ou les liaisons Internet haut débit. Rappelez-vous que vous avez défini ces deux interfaces dans l’instance de routage principale.
Ajoutez le nouveau profil apbr_profile au trust de la zone de sécurité. Cette configuration applique le profil au trafic de la zone.
Validez la configuration et revenez en mode opérationnel.

Vérifier la qualité de l’expérience applicative

But
Action
Sens

But

Vérifiez que l’APBR fonctionne conformément aux objectifs de cet exemple.

Action

Générez un mélange de trafic critique et non critique à partir d’un client filaire ou sans fil. Délivrez ensuite les commandes de cette section pour vérifier que l’ABPR fonctionne correctement.

Commencez par confirmer que les sondes RPM réussissent sur les liaisons primaires et secondaires. Pour gagner de l’espace, nous n’afficherons que les sondes de l’application critique. Toutes les sondes doivent réussir à ce moment. Affichez les résultats des sondes RPM à l’aide des show services rpm probe-results owner office365_rpm_primary commandes (et secondaires).

La sortie confirme que les sondes critiques des applications métiers réussissent actuellement sur les liaisons primaire et secondaire. Vous attendez des résultats similaires pour les sondes applicatives non critiques, avec les interfaces primaires et secondaires inversées.

Ensuite, affichez une instance de routage pour vérifier l’état de transfert lorsque les interfaces primaires et secondaires sont opérationnelles. Émettre la show route table <instance-name> commande pour les applications critiques et non critiques.

La sortie confirme que le trafic classé Office 365 utilise la liaison WAN privée. En tant qu’application stratégique, l’instance de routage comporte à la fois un saut secondaire et un saut supérieur supérieur supérieur. Lorsque les deux premiers sauts deviennent indisponibles, le trafic critique tombe sur le modem LTE. En revanche, l’application non critique utilise la liaison Internet haut débit pour transférer le trafic. Si ce saut suivant devient indisponible, l’instance dirige le trafic vers le WAN privé. Le modem LTE n’est pas répertorié dans cette instance de routage. Cette omission empêche toute application non critique d’utiliser la liaison LTE.

Rappelez-vous que les sondes de surveillance SLA passent par Internet vers le fournisseur d’applications. La nature de bout en bout des sondes permet au SRX de mesurer les performances de bout en bout de l’application. La mesure de « l’expérience au niveau de l’application » contraste avec la détection simple des défaillances de liaison ou de saut suivant en fonction de l’état de l’interface ou de la détection de transfert bidirectionnel (BFD), respectivement.

En option : perturbez les sondes RPM pour confirmer que le trafic critique utilise la liaison Internet haut débit. Vous pouvez simuler des défaillances de sonde SLA avec un filtre de pare-feu appliqué dans la direction de sortie de l’interface WAN privée sur l’équipement SRX.

Avec le filtre en place sur la liaison WAN privée, vous vous attendez à trouver l’application critique transmise via la liaison Internet haut débit.

Avec l’échec des sondes principales, la stratégie de surveillance SLA a modifié la préférence de routage statique dans l’instance de routage d’application critique. Résultat : les flux de trafic critiques transitent par la liaison Internet haut débit. Ce comportement confirme le bon fonctionnement de la surveillance des performances des SLA IP.

Note:

N’oubliez pas de restaurer la modification du filtre de pare-feu au niveau du SRX ! Une fois reroulée, l’instance de routage de l’application critique sera réacheminée vers la liaison WAN privée.

Vous pouvez surveiller les statistiques de trafic APBR avec la show security advance-policy-based-routing statistics commande.

La sortie affiche les détails statistiques de l’APBR. Les détails incluent le nombre de sessions traitées par la règle APR et le nombre de fois que le trafic de l’application correspond au profil APBR (résultat de la règle).

Sens

Les commandes et la sortie affichées dans cette section confirment que l’APBR fonctionne correctement sur la passerelle de services SRX. Votre nouvelle filiale gérée par Juniper Mist Cloud est prête pour les affaires.