Mesure de la Cos réseau avec Cisco IP-SLA : support du mode « Tagué »

Afin de répondre à certaines contraintes opérateurs pour les mesures des performances des classes de service réseau (Cos), le portail Alaloop peut désormais programmer directement le champ TOS/DSCP sur les routeurs dédiés de mesure (Shadows routeurs).

Bref rappel sur la mesure de performances réseau

Les mesures de performance réseau (avec ou sans Cos) sont réalisées à l’aide de l’opération IP-SLA Jitter qui nécessite la mise en oeuvre d’un responder IP-SLA sur les sites distants.

Grâce à la gestion des Timestamps intégrée aux agents IP-SLA, le délai réseau RTT (Round Trip Time) entre les routeurs source & destination fourni par une mesure IP-SLA jitter est indépendant de la charge de ces derniers. En effet, les routeurs impliqués positionnent un Timestamp à l’arrivée/départ des paquets de test. Ce mécanisme inhérent à IP-SLA permet de déduire le temps passé dans les routeurs de mesure du temps global, comme l’explique le schéma ci-dessus. Inversement, nous avons démontré qu’un délai réseau fourni par une mesure ICMP (Ping) est très fortement influencé par la charge CPU du routeur (ou de l’élément) distant et ne permet donc pas de disposer d’une mesure réseau cohérente.

La mesure des classes de service réseau

La mesure des classes de services réseau entre les DATA Center et les sites distants permet de vérifier que les contraintes de transport des flux d’application sont bien respectées. Afin de sélectionner la classe de service à mesurer, les portails Alaloop supportent désormais un nouveau mode de programmation des opérations IP-SLA, le mode « Tagué ». Il consiste à programmer directement le routeur de mesure (Shadow Router) avec la classe de service à mesurer. Les paquets de test IP générés par le Shadow Routeur seront alors émis avec la classe de service renseignée dans le champ TOS/DSCP. Il faut alors que le routeur CE d’accès au réseau WAN n’effectue pas une nouvelle classification du paquet pour le positionner dans une autre classe de service en changeant la valeur du champ TOS/DSCP.

Ce mode vient compléter le mode « User » utilisé par défaut par les portails Alaloop, qui consiste à instruire le routeur Shadow pour générer des paquets conformes à la politique de Cos du réseau et qui seront classifiés par le routeur CE d’accès au réseau WAN.

Résumé des modes de programmation des opérations Cisco IP-SLA

Le portail Alaloop supporte donc désormais les 3 modes de programmation suivants : 1.mode « user » : les mesures des routeurs Shadow produisent des paquets IP conformes à la politique de Cos de l’utilisateur. Ils sont classifiés dans la classe de service par le routeur CE d’accès au WAN ; 2.mode « tagué » : les mesures des routeurs Shadow produisent des paquets IP déjà classifiés dans la classe de service à mesurer (champ TOS/DSCP renseigné). Il faut s’assurer que le routeur CE d’accès au WAN ne modifie pas cette classification ; 3.mode « multi-VPN » : les mesures des routeurs Shadow produisent des paquets IP dans le VPN à tester. Cela suppose que les VRF (tables de routage des VPNs) soient propagées sur le routeur Shadow puisque le portail Alaloop spécifiera le numéro de VRF pour sélectionner le VPN à mesurer.

Gestion des états « critical »

Prise en compte d’un état « Critical » pour le calcul d’un SLA fonction de l’état de plusieurs mesures.

Si les mesures de performance sont utilisées pour valider un SLA (conséquences financières), il est important de pouvoir définir avec précision ce que l’on considère comme état « Critical » au sens du SLA.

On pourra considérer par exemple, qu’une mesure est « Critical » pour le calcul des SLAs, si et seulement si deux mesures consécutives sont dans un état « Critical ». Ce comportement permet d’éliminer des « micro congestions » au moment même de la mesure, qui se traduit par 5 minutes de « Critical » au sens du SLA en raison de l’intervalle de mesure par défaut.

Remarque : cette fonctionnalité peut être utilisé concurremment avec un intervalle de mesure plus fin si nécessaire (par exemple une mesure toutes les deux minutes).

Corrections dans SLA Dashboards

Dans certains cas, l’arborescence des vues de navigation (sur la partie gauche des écrans SLA Dashboards) ne s’affichait pas correctement. En outre, les vues étaient affichées dans l’ordre de saisie de la stratégie de mesure.

Les vues sont désormais classées par ordre alphabétique

Améliorations du SLA reporting

Duplication de rapport : la liste des rapports donne accès à une fonction de duplication de rapport. Cette fonction est utile notamment pour conserver une structure de rapports identiques en modifiant seulement des options de présentation.

Gestion d’échelle sur les graphes (échelle fixe / variable) : les graphes des rapports peuvent être défini en échelle variable (Autoscale) en fixant la valeur maximale et/ou minimale de telle sorte à écarter les pics de mesure qui provoquent un écrasement des courbes (cut de pics de valeur). Il est également possible de définir une échelle fixe (FixedScale) pour le graphe en spécifiant également les valeurs min et max. Les rapports de performance destinés à un usage d’exploitant seront généralement basés sur des graphes à échelle variable, alors que les rapports de performance pour le suivi de SLA seront basés sur une échelle fixe.

Liste des états de mesure (states logs) : en complément du tableau de SLA sur la période sélectionnée, il est possible d’obtenir la liste des événements relatifs à un état de mesure. Par exemple, si la mesure réseau d’une classe de service Gold est en état « Warning » sur 2% du temps sur la période sélectionnée, il sera possible de connaître les plages horaires précises de ces ralentissements.

Analyses de trafic (Netflow)

Amélioration de l’interface
Affichage des listes sous Internet Explorer
Affichage alphabétique des objets Netflow
Suppression de la sélection par défaut du 1er objet Netflow de la liste

Affichage du champ TOS/DSCP dans la requête Flow-Search

Le champ TOS (DSCP) est affiché dans la fonction « Display Flows » des requêtes Netflow - Flow Search. La prochaine release (Version 3.2) permettra d’afficher le nom éventuel associé au champ Tos (exemple : Gold, Silver, Bronze, ...)

Haut de page