Surveiller la qualité du service réseau à l’aide de RMON

Définition des seuils

En définissant un seuil ascendant et un seuil descendant pour une variable surveillée, vous pouvez être alerté chaque fois que la valeur de la variable tombe en dehors de la plage opérationnelle autorisée. (Reportez-vous à la section Figure 1.)

Figure 1 : Définition des seuils

Les événements ne sont générés que lorsque le seuil est franchi pour la première fois dans une direction plutôt qu’après chaque période d’échantillonnage. Par exemple, si un événement de franchissement de seuil ascendant est déclenché, aucun autre événement de franchissement de seuil ne se produira jusqu’à ce qu’un événement de franchissement de seuil correspondant se produise. Cela réduit considérablement la quantité d’alarmes produites par le système, ce qui permet au personnel d’exploitation de réagir plus facilement lorsque des alarmes se produisent.

Pour configurer la surveillance à distance, spécifiez les informations suivantes :

• La variable à surveiller (par son identifiant d’objet SNMP)

• Le temps écoulé entre chaque inspection

• Un seuil qui s’élève

• Un seuil descendant

• Un événement en plein essor

• Un événement de chute

Avant de pouvoir configurer la surveillance à distance, vous devez identifier les variables à surveiller et leur plage de fonctionnement autorisée. Cela nécessite une certaine période de référence pour déterminer les plages opérationnelles autorisées. Il n’est pas inhabituel d’avoir une période de référence initiale d’au moins trois mois lorsqu’il s’agit d’identifier les plages opérationnelles et de définir des seuils, mais la surveillance de base doit se poursuivre tout au long de la durée de vie de chaque variable surveillée.

Interface de ligne de commande RMON

Junos OS fournit deux mécanismes que vous utilisez pour contrôler l’agent de surveillance à distance sur le routeur : interface de ligne de commande (CLI) et SNMP. Pour configurer une entrée RMON à l’aide de l’interface de ligne de commande, incluez les instructions suivantes au niveau de la [edit snmp] hiérarchie :

Si vous ne disposez pas d’un accès CLI, vous pouvez configurer la surveillance à distance à l’aide du gestionnaire SNMP ou de l’application de gestion, en supposant que l’accès SNMP a été accordé. (Reportez-vous à la section Tableau 1.) Pour configurer RMON à l’aide de SNMP, effectuez des requêtes SNMP Set vers les tables d’événements et d’alarmes RMON.

Table d’événements RMON

Configurez un événement pour chaque type que vous souhaitez générer. Par exemple, vous pouvez avoir deux événements génériques, croissant et décroissant, ou de nombreux événements différents pour chaque variable surveillée (par exemple, événement d’augmentation de température , événement de baisse de température , événement d’impact de pare-feu , événement d’utilisation d’interface , etc.). Une fois les événements configurés, vous n’avez pas besoin de les mettre à jour.

Tableau d’alarme RMON

La table d’alarmes RMON stocke les identificateurs d’objets SNMP (y compris leurs instances) des variables surveillées, ainsi que tous les seuils ascendants et descendants et leurs index d’événements correspondants. Pour créer une requête RMON, spécifiez les champs affichés dans Tableau 2.

Les champs et eventStatus sont des primitives, telles que définies dans la alarmStatus RFC 2579, Conventions textuelles pour SMIv2entryStatus.

Dépannage RMON

Vous dépannez l’agent RMON, rmopd, qui s’exécute sur le routeur en inspectant le contenu de la MIB RMON d’entreprise de Juniper Networks, jnxRmon, qui fournit les extensions répertoriées dans Tableau 3 la RFC 2819 alarmTable.

La surveillance des extensions de ce tableau fournit des indices sur les raisons pour lesquelles les alarmes à distance peuvent ne pas se comporter comme prévu.

Points de mesure

Il est tout aussi important de définir les points de mesure où les mesures sont mesurées que de définir les mesures elles-mêmes. Cette section décrit les points de mesure dans le contexte de ce chapitre et permet d’identifier les endroits où les mesures peuvent être effectuées à partir d’un réseau de fournisseurs de services. Il est important de comprendre exactement où se trouve un point de mesure. Les points de mesure sont essentiels pour comprendre l’implication de ce que signifie la mesure réelle.

Un réseau IP est constitué d’un ensemble de routeurs connectés par des liaisons physiques qui exécutent tous le protocole Internet. Vous pouvez visualiser le réseau comme un ensemble de routeurs avec un point d’entrée (entrée) et un point de sortie (sortie). Reportez-vous à la section Figure 2.

• Les mesures centrées sur le réseau sont effectuées aux points de mesure qui correspondent le mieux aux points d’entrée et de sortie du réseau lui-même. Par exemple, pour mesurer le retard sur le réseau du fournisseur entre le site A et le site B, les points de mesure doivent être le point d’entrée vers le réseau du fournisseur sur le site A et le point de sortie sur le site B.

• Les mesures centrées sur les routeurs sont prises directement à partir des routeurs eux-mêmes, mais veillez à ce que les sous-composants corrects du routeur aient été identifiés à l’avance.

Figure 2 : Points d’entrée réseau

Indicateurs clés de performance de base

Par exemple, vous pouvez surveiller le réseau d’un fournisseur de services à l’aide de trois indicateurs clés de performance (KPI) de base :

• mesure « l’accessibilité » d’un point de mesure par rapport à un autre point de mesure au niveau de la couche réseau (par exemple, en utilisant le ping ICMP). L’infrastructure de routage et de transport sous-jacente du réseau du fournisseur prend en charge les mesures de disponibilité, les échecs étant mis en évidence comme indisponibles.

• mesure le nombre et le type d’erreurs qui se produisent sur le réseau du fournisseur et peut consister en des mesures centrées sur le routeur et sur le réseau, telles que les pannes matérielles ou la perte de paquets.

• du réseau du fournisseur mesure sa capacité à prendre en charge les services IP (par exemple, en termes de délai ou d’utilisation).

Définition des lignes de base

Quel est le niveau de performance du réseau de fournisseurs ? Nous recommandons une première période de surveillance de trois mois afin d’identifier les paramètres opérationnels normaux d’un réseau. Grâce à ces informations, vous pouvez reconnaître les exceptions et identifier les comportements anormaux. Vous devez poursuivre la surveillance de base pendant toute la durée de vie de chaque métrique mesurée. Au fil du temps, vous devez être en mesure de reconnaître les tendances de performance et les modèles de croissance.

Dans le contexte du présent chapitre, bon nombre des paramètres identifiés ne sont pas associés à une plage opérationnelle admissible. Dans la plupart des cas, vous ne pouvez pas identifier la plage opérationnelle autorisée tant que vous n’avez pas déterminé une référence pour la variable réelle sur un réseau spécifique.

Définir la disponibilité du réseau

La disponibilité du réseau IP d’un fournisseur de services peut être considérée comme l’accessibilité entre les points de présence régionaux (POP), comme illustré à la .Figure 3

Figure 3 : Points de présence régionaux

Avec l’exemple ci-dessus, lorsque vous utilisez un maillage complet de points de mesure, où chaque POP mesure la disponibilité par rapport à tous les autres POP, vous pouvez calculer la disponibilité totale du réseau du fournisseur de services. Cet indicateur clé de performance (KPI) peut également être utilisé pour surveiller le niveau de service du réseau, et peut être utilisé par le fournisseur de services et ses clients pour déterminer s’ils respectent les termes de leur accord de niveau de service (SLA).

Lorsqu’un POP peut être constitué de plusieurs routeurs, effectuez des mesures sur chacun d’eux, comme illustré à Figure 4la .

Figure 4 : Mesures pour chaque routeur

Les mesures comprennent :

• Path availability (Disponibilité du chemin) : disponibilité d’une interface de sortie B1 vue à partir d’une interface d’entrée A1.

• Router availability (Disponibilité du routeur) : pourcentage de disponibilité des chemins de tous les chemins mesurés se terminant sur le routeur.

• Disponibilité POP : pourcentage de disponibilité du routeur entre deux POP régionaux, A et B.

• Disponibilité du réseau : pourcentage de disponibilité des POP pour tous les POP régionaux du réseau du fournisseur de services.

Pour mesurer la disponibilité POP du POP A vers le POP B en Figure 4, vous devez mesurer les quatre chemins suivants :

Mesurer la disponibilité du POP B au POP A nécessiterait quatre mesures supplémentaires, et ainsi de suite.

Un maillage complet de mesures de disponibilité peut générer un trafic de gestion important. D’après l’exemple de schéma ci-dessus :

• Chaque POP dispose de deux routeurs Provider Edge (PE) colocalisés, chacun avec 2 interfaces STM1, pour un total de 18 routeurs PE et 36 interfaces STM1.

• Il existe six routeurs Core Provider (P), quatre avec 2xSTM4 et 3xSTM1 chacun, et deux avec 3xSTM4 et 3xSTM1 chacun.

Cela fait un total de 68 interfaces. Un maillage complet de chemins entre chaque interface est :

[n x (n–l)] / 2 donne [68 x (68–1)] / 2=2278 chemins

Pour réduire le trafic de gestion sur le réseau du fournisseur de services, au lieu de générer un maillage complet de tests de disponibilité des interfaces (par exemple, de chaque interface à toutes les autres interfaces), vous pouvez effectuer des mesures à partir de l’adresse de bouclage de chaque routeur. Cela réduit le nombre de mesures de disponibilité requises à un total d’une pour chaque routeur, ou :

n[ x (n–1)] / 2 donne [24 x (24–1)] / 2=276 mesures

Cela mesure la disponibilité de chaque routeur à tous les autres routeurs.

Mesurer la disponibilité

Il existe deux méthodes que vous pouvez utiliser pour mesurer la disponibilité :

• Proactif : la disponibilité est mesurée automatiquement aussi souvent que possible par un système d’assistance opérationnelle.

• Réactif : la disponibilité est enregistrée par un support technique lorsqu’une défaillance est signalée pour la première fois par un utilisateur ou un système de surveillance des pannes.

Cette section traite de la surveillance des performances en temps réel en tant que solution de surveillance proactive.

Mesurer la classe de service

Vous pouvez utiliser des mécanismes de classe de service (CoS) pour réguler la manière dont certaines classes de paquets sont traitées au sein de votre réseau pendant les pics de congestion. En règle générale, vous devez effectuer les étapes suivantes lors de l’implémentation d’un mécanisme CoS :

• Identifiez le type de paquets qui est appliqué à cette classe. Par exemple, vous pouvez inclure tout le trafic client provenant d’une interface de périphérie entrante spécifique au sein d’une classe, ou inclure tous les paquets d’un protocole particulier tel que la voix sur IP (VoIP).

• Identifiez le comportement déterministe requis pour chaque classe. Par exemple, si la VoIP est importante, donnez la priorité la plus élevée au trafic VoIP en période de congestion du réseau. À l’inverse, vous pouvez réduire l’importance du trafic Web en cas de congestion, car il peut ne pas avoir trop d’impact sur les clients.

Grâce à ces informations, vous pouvez configurer des mécanismes à l’entrée du réseau pour surveiller, marquer et contrôler les classes de trafic. Le trafic marqué peut ensuite être traité de manière plus déterministe au niveau des interfaces de sortie, généralement en appliquant des mécanismes de file d’attente différents pour chaque classe en période de congestion du réseau. Vous pouvez collecter des informations sur le réseau pour fournir aux clients des rapports montrant comment le réseau se comporte en période d’encombrement. (Reportez-vous à la section Figure 5.)

Figure 5 : Comportement du réseau en cas d’encombrement

Pour générer ces rapports, les routeurs doivent fournir les informations suivantes :

• Trafic envoyé : quantité de trafic reçu par classe.

• Trafic distribué : quantité de trafic transmis par classe.

• Trafic abandonné : quantité de trafic abandonnée en raison des limites CoS.

La section suivante décrit comment ces informations sont fournies par les routeurs Juniper Networks.

Compteurs de filtres de pare-feu entrants par classe

Les compteurs de filtres de pare-feu sont un mécanisme très flexible que vous pouvez utiliser pour faire correspondre et compter le trafic entrant par classe et par interface. Par exemple :

Par exemple, Tableau 8 affiche des filtres supplémentaires utilisés pour faire correspondre les autres classes.

Tout paquet avec un point de code CoS DiffServ (DSCP) conforme à la RFC 2474 peut être compté de cette manière. La MIB de filtre de pare-feu spécifique à l’entreprise de Juniper Networks présente les informations du compteur dans les variables illustrées à la .Tableau 9

Ces informations peuvent être collectées par n’importe quelle application de gestion SNMP prenant en charge SNMPv2. Les produits de fournisseurs tels que Concord Communications, Inc. et InfoVista, Inc. prennent en charge la MIB du pare-feu Juniper Networks avec leurs pilotes de périphérique Juniper Networks natifs.

Surveiller les octets de sortie par file d’attente

Vous pouvez utiliser la MIB CoS ATM d’entreprise de Juniper Networks pour surveiller le trafic sortant, par classe de transfert de circuit virtuel et par interface. (Reportez-vous à la section Tableau 10.)

Les compteurs d’interface autres que les distributeurs automatiques de billets sont fournis par la MIB CoS spécifique à l’entreprise de Juniper Networks, qui fournit les informations illustrées à Tableau 11la .

Calculer la perte de trafic

Vous pouvez calculer la quantité de trafic abandonné en soustrayant le trafic sortant du trafic entrant :

Vous pouvez également sélectionner des compteurs à partir de la MIB CoS, comme illustré à Tableau 12la .