Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Surveillance des ressources pour la gestion des abonnés et les services

Surveillance des ressources pour la gestion des abonnés et la présentation des services

Junos OS prend en charge une fonctionnalité de surveillance des ressources à l’aide des requêtes MIB CLI et SNMP. Vous pouvez utiliser cet utilitaire pour provisionner une marge de manœuvre suffisante (limites d’espace mémoire pour l’application ou le routeur virtuel) afin de garantir la stabilité du système, en particulier l’intégrité et l’efficacité opérationnelle des cartes d’interface basées sur une puce I et des SPC basés sur Trio sur les routeurs MX Series.

Lorsque l’utilisation de la mémoire , soit la mémoire ukernel ou la mémoire ASIC, atteint un certain seuil, les opérations du système compromettent l’intégrité et la stabilité du trafic de la carte d’interface. Un tel compromis sur les performances du système peut nuire à la prise en charge du trafic et des protocoles en temps réel.

Outre la possibilité de configurer un seuil pour augmenter les journaux d’erreurs en cas de dépassement d’un seuil spécifique de ressources, vous pouvez également surveiller les valeurs de seuil et l’utilisation des ressources à l’aide de requêtes MIB SNMP.

Les sections suivantes décrivent les types de surveillance des ressources disponibles avec Junos OS :

Utilisation de Watermarks pour la surveillance des ressources des cartes de ligne

Vous pouvez configurer des valeurs de watermark ou de point de contrôle pour les ressources de carte de ligne, telles que la mémoire ukern (heap), la mémoire du prochain saut (NH) et la mémoire du pare-feu ou du filtre, pour qu’elles soient uniformes pour les cartes d’interface basées sur Trio et sur puce I. Le watermark de la mémoire NH ne s’applique qu’à la mémoire d’encapsulation (mémoire RAM statique WAN de sortie). La mémoire d’encapsulation est spécifique aux puces I et ne s’applique pas aux puces basées sur Trio. Lorsque le watermark configuré est dépassé, les journaux d’erreurs sont déclenchés. Si la ressource a été utilisée au-dessus d’un certain seuil, des messages d’avertissement sont générés dans le journal du système pour signaler que la valeur du seuil a dépassé. En fonction des besoins de votre réseau, vous pouvez ensuite déterminer si vous souhaitez mettre fin aux abonnés et services existants pour éviter que le système ne soit surchargé et n’entraîne une panne.

Cette fonctionnalité recueille les données de chacune des cartes d’interface et transfère ce détail statistique au processus du moteur de routage à l’aide d’un port interne bien connu. Ces informations sont analysées par le démon du moteur de routine et, à l’aide de l’espace mémoire partagé intégré à la base de données de session, des messages d’avertissement sont générés pour les conditions de dépassement du seuil.

La possibilité de configurer la surveillance des ressources est prise en charge sur les routeurs MX80, MX104 et sur les cartes de ligne suivantes sur les routeurs MX240, MX480, MX960, MX2010 et MX2020 :

  • MX-MPC1-3D

  • MX-MPC1-3D-Q

  • MX-MPC2-3D

  • MX-MPC2-3D-Q

  • MX-MPC2-3D-EQ

  • MPC-3D-16XGE-SFPP

  • MPC3E

  • MPC3E-3D-NG

  • MPC4E-3D-2CGE-8XGE

  • MPC4E-3D-32XGE

  • MPC5EQ-40G10G

  • MPC5EQ-100G10G

  • MPC5E-100G10G

  • MPC5E-40G10G

  • MPC10E-10C-MRATE

  • MPC10E-15C-MRATE

  • MX2K-MPC6E

  • MX2K-MPC11E

  • DPCE

  • MS-DPC

  • Concentrateurs PIC flexibles MX Series (MX-FPCs)

  • NG-MPC3E

Vous pouvez configurer les paramètres suivants au niveau de la [edit system services] hiérarchie pour spécifier la valeur de seuil élevé commune à tous les espaces ou régions de mémoire, ainsi que les valeurs de watermark pour les différents blocs de mémoire sur les DPC et les MPC :

  • Valeur seuil élevé, dépassant les avertissements ou les journaux d’erreurs générés, pour toutes les régions de la mémoire, telles que heap ou ukernel, le saut suivant et l’encapsulation, et la mémoire du filtre de pare-feu, à l’aide de l’instruction resource-monitor high-threshold value .

  • Pourcentage d’espace mémoire libre utilisé pour les sauts suivants à surveiller avec une valeur de watermark à l’aide de l’instruction resource-monitor free-nh-memory-watermark percentage .

  • Pourcentage de l’espace mémoire libre utilisé pour la mémoire d’ukernel ou de tas à surveiller avec une valeur de watermark à l’aide de l’instruction resource-monitor free-heap-memory-watermark percentage .

  • Pourcentage de l’espace mémoire libre utilisé pour la mémoire du pare-feu et du filtre à surveiller avec une valeur watermark à l’aide de l’instruction resource-monitor free-fw-memory-watermark percentage . Cette fonctionnalité est activée par défaut et vous ne pouvez pas la désactiver manuellement. La valeur par défaut et la valeur configurée de la valeur de watermark pour le pourcentage de mémoire libre du saut suivant s’applique également à la mémoire d’encapsulation.

Les valeurs de repère par défaut pour le pourcentage de mémoire libre ukernel ou heap, de mémoire du saut suivant et de mémoire de filtre de pare-feu sont les suivantes :

  • free-heap-memory-watermark—20

  • free-nh-memory-watermark—20

  • free-fw-memory-watermark —20

Limitation de la charge des abonnés en fonction de la capacité des ressources CoS

À partir de la version 17.4R1 de Junos OS, des critères de classe de service (CoS) sont intégrés à la décision de limitation de l’accès des abonnés. Les informations sur la disponibilité des ressources CoS, à savoir la capacité des files d’attente, sont collectées à partir des cartes d’interface. Lors de la connexion de l’abonné, en supposant que l’abonné a besoin de ressources CoS, les cartes d’interface signalent l’utilisation de la file d’attente CoS en tant que pourcentage des ressources liées à une hiérarchie de planification et qui ne sont pas libres d’être liées à une nouvelle hiérarchie de planification. L’instruction high-cos-queue-threshold au niveau de la [edit system services] hiérarchie peut être définie entre 0 % et 90 %, séparément pour chaque emplacement FPC. Lorsque l'utilisation de la file d'attente CoS sur un FPC donné atteint le seuil configuré de ce FPC, d'autres connexions d'abonnés sur ce FPC ne sont pas autorisées. Ce mécanisme de surveillance des ressources offre des marges de sécurité ajustables afin d'éviter d'épuiser complètement les ressources de file d'attente CoS disponibles de chaque FPC. Voir high-cos-queue-threshold.

Note:

Cette fonctionnalité n’est disponible que lorsque vous activez la gestion des abonnés. Pour plus d’informations sur la gestion des abonnés, voir Configuration de la gestion améliorée des abonnés de Junos OS.

Note:

À partir de la version 19.4R1 de Junos OS, vous pouvez spécifier une valeur 0 pour éviter qu’un abonné ne soit limité par la limitation basée sur les files d’attente.

Cette fonctionnalité de surveillance des ressources CoS base les décisions d’admission uniquement sur les files d’attente. Les autres ressources coS ne font pas partie de ce critère. Cette fonctionnalité ne prend pas en charge la limitation pour les abonnés arrivant sur un pseudo-câble, un tunnel logique ou des équipements de tunnel logique redondants. Cette fonctionnalité est prise en charge sur le matériel suivant :

  • Routeurs MX240, MX480 et MX960

  • Cartes d’interface MPC2E héritées, MPC2E-NG, MPC3E-NG, MPC5E et MPC7E

Examen de l’utilisation des régions de ressources mémoire à l’aide des commandes show

Vous pouvez utiliser la show system resource-monitor fpc commande pour surveiller l’utilisation des ressources de mémoire sur les moteurs de transfert de paquets d’un FPC. La mémoire du filtre désigne la mémoire du compteur de filtre utilisé pour les compteurs de filtres de pare-feu. L’astérisque (*) affiché à côté de chacune des régions mémoire désigne les régions pour lesquelles le seuil configuré est actuellement dépassé. Les commandes de surveillance des ressources affichent les valeurs configurées de watermark pour les mémoires des différentes applications de carte de ligne à surveiller. Les métriques statistiques affichées sont basées sur le calcul effectué sur l’utilisation actuelle de la mémoire des cartes d’interface individuelles. La mémoire ukern est générique sur les différents types de cartes d’interface et signifie les mémoires tampons de mémoire du tas. Étant donné qu’une carte de ligne ou un FPC dans un emplacement particulier peut contenir plusieurs complexes de moteurs de transfert de paquets, la mémoire utilisée sur les circuits intégrés spécifiques aux applications (ASIC) est spécifique à un complexe PFE particulier. En raison de modèles d’architecture différents pour différentes variantes de cartes d’interface prises en charge, le pourcentage d’utilisation de la mémoire spécifique à ASIC (prochain saut et mémoire du pare-feu ou du filtre) peut être interprété différemment.

Limitation de la charge pour réduire les retards de traitement

À partir de la version 17.3R1 de Junos OS, le moteur de routage peut utiliser la surveillance des ressources pour évaluer et réduire la charge de traitement sur le moteur de transfert de paquets d’une carte de ligne. Il est possible pour le moteur de routage d’envoyer du travail à un débit plus élevé que celui que le moteur de transfert de paquets peut traiter. C’est ce que l’on appelle parfois overdriving la carte d’interface ou le moteur de transfert de paquets. Lorsque la charge de travail sur le moteur de transfert de paquets est trop élevée, cela peut entraîner des retards notables dans le traitement des paquets.

La surveillance des ressources permet au moteur de routage d’évaluer la charge en évaluant le délai d’aller-retour des paquets qu’il envoie au moteur de transfert de paquets. Un temps d’aller-retour plus long indique une charge plus élevée et donc une plus grande probabilité de retards de traitement sur le moteur de transfert de paquets. Le cas échéant, le moteur de routage réduit le pourcentage de sessions d’abonnés (client et service) autorisées à s’effectuer.

Cette fonctionnalité est appelée limitation de charge ou limitation de charge en aller-retour. La limitation empêche le moteur de routage de sur-piloter les cartes d’interface au point que les retards de traitement deviennent visibles par les opérateurs et les systèmes de back-office. Cela fonctionne comme ceci :

  1. Pour surveiller les retards, le moteur de routage envoie un message de demande d’écho chaque seconde au moteur de transfert de paquets sur la carte de ligne. La demande d’écho comprend à la fois un horodatage pour l’envoi et un numéro de séquence en cours d’exécution. La priorité du message est le meilleur effort, pour simuler le pire retard de traitement des cas sur la carte d’interface.

  2. Le moteur de transfert de paquets traite la demande d’écho et répond par une réponse d’écho. La priorité du message est élevée pour minimiser la gigue lorsque le moteur de routage traite le paquet retourné.

  3. Lorsque le moteur de routage reçoit la réponse d’écho, il calcule le temps d’aller-retour comme la différence de temps entre l’horodatage de la demande d’écho et le moment où il reçoit la réponse d’écho pour ce numéro de séquence particulier.

  4. Le moteur de routage compare le temps de retard d’aller-retour à une valeur seuil d’aller-retour par défaut de 1 seconde. Si le délai mesuré est supérieur au seuil de trois déplacements consécutifs, le moteur de routage refuse les connexions pour un pourcentage de nouveaux abonnés, ce qui réduit le nombre de nouvelles sessions client et de service qui sont établies. Cette réduction est appelée limitation.

    Un algorithme interne tire le pourcentage de limitation en fonction du seuil et du temps d’aller-retour. Ce pourcentage varie en fonction du délai d’aller-retour à ce moment-là.

    Le moteur de routage augmente l’accélérateur et refuse davantage de connexions d’abonnés pour chaque série successive de trois mesures de retard qui dépassent toutes le seuil.

  5. Lorsque le délai mesuré est inférieur au seuil de trois déplacements consécutifs, le moteur de routage retire l’accélérateur. Les abonnés peuvent ainsi se connecter librement.

Note:

La limitation de charge RTT s’applique sur une carte par ligne pour les interfaces Ethernet (ge, xe) et les interfaces pseudowire (ps) comme suit :

  • Pour les interfaces Ethernet agrégées, elle s’applique à l’ensemble de cartes d’interface associées à l’offre Ethernet agrégée.

  • Pour les interfaces pseudowire avec tunnel logique redondant (RLT), elle s’applique à l’ensemble des cartes de ligne associées au point d’ancrage.

Dans les deux cas, le moteur de routage considère que la valeur de retard qui détermine la limitation est le plus long délai d’aller-retour de toutes les cartes d’interface de l’ensemble.

Le tableau 1 montre comment les sessions des abonnés sont limitées sur une carte d’interface sur une période de 12 secondes lorsque le délai d’aller-retour est supérieur au seuil interne. Cet exemple présente les hypothèses suivantes :

  • Le délai interne est de 1 seconde.

  • Les mesures de retard sont effectuées toutes les secondes.

  • Le taux de création de session est réduit de 10 % après 3 mesuresconsécutivesnaires consécutives au-dessus du seuil de retard. Tant que le seuil est dépassé, la limitation est augmentée toutes les 3 mesures.

  • Si le délai mesuré tombe et reste en dessous du seuil de 3 mesuresdesnaires consécutives, le taux de session revient à 100 %.

Note:

Cet exemple est simplifié. N’oubliez pas que le pourcentage exact de limitation est déterminé dynamiquement et peut varier d’une seconde à l’autre.

Tableau 1 : Exemple de limitation de charge due au temps de retard d’aller-retour

Temps

Délai aller-retour (ms)

Seuil dépassé

Pourcentage de sessions autorisées

1

850

Non

100

2

900

Non

100

3

995

Non

100

4

1021

Oui

Seuil dépassé le nombre #1

100

5

1130

Oui

Seuil dépassé le nombre #2

100

6

1158

Oui

Seuil dépassé le nombre #3

90

Taux de session réduit de 10 %

7

1127

Oui

Seuil dépassé le nombre #1

90

Taux de session réduit de 10 %

8

1135

Oui

Seuil dépassé le nombre #2

90

9

1126

Oui

Seuil dépassé le nombre #3

80

Taux de session réduit de 10 %

10

1000

Non

Seuil non dépassé compte #1

80

11

991

Non

Seuil ne dépassant pas le nombre #2

80

12

998

Non

Seuil non dépassé nombre #3

100

Suppression de la limitation

La surveillance de la charge des ressources et la limitation du temps d’aller-retour sont activées par défaut. Vous pouvez utiliser l’une des instructions suivantes pour désactiver cette fonctionnalité :

  • no-load-throttle au niveau de la [edit system services resource-monitor] hiérarchie

  • no-throttle au niveau de la [edit system services resource-monitor] hiérarchie

Si vous désactivez la fonctionnalité et que le moteur de transfert de paquets devient trop occupé, les nouveaux abonnés peuvent se connecter et être actifs, mais aucun trafic ne circule pendant un certain temps. Ce retard dans le traitement du trafic peut se faire remarquer.

Vous pouvez utiliser la commande suivante pour confirmer si la fonctionnalité de limitation de charge est activée et voir divers aspects de la fonctionnalité en action. Les champs audacieux sont particulièrement utiles.

Limiter le nombre d’abonnés avec Resource Monitor

À partir de la version 17.3R1 de Junos OS, vous pouvez également utiliser la surveillance des ressources pour limiter directement le nombre d’abonnés pris en charge par élément matériel. Vous pouvez spécifier le nombre maximal d’abonnés pouvant être connectés par châssis, carte d’interface (MPC), MIC ou port. Vous pouvez définir la limite aux abonnés d’un seul type de client (DHCP, L2TP ou PPPoE) ou aux abonnés de n’importe quel type de client.

Cette fonctionnalité garantit que le nombre d’abonnés connectés par élément matériel ne dépasse pas le nombre que votre réseau peut servir avec stabilité à la bande passante de service souhaitée. Lorsque la limite est atteinte pour un élément matériel, les connexions des nouveaux abonnés sont refusées sur cet élément jusqu’à ce que le nombre d’abonnés passe en-dessous de la limite configurée. Les nouveaux abonnés au-dessus de la limite peuvent se connecter à un autre élément matériel du même domaine de diffusion. Lorsque vous configurez la limite sur une ou plusieurs jambes d’une interface Ethernet agrégée, la connexion est refusée si le nombre d’abonnés dépasse la valeur sur l’une des jambes.

Limiter les abonnés de cette façon répartit la charge entre les éléments matériels, mais ne fournit aucun type d’équilibrage de charge. Cette fonctionnalité peut également vous aider à cartographier la capacité de votre réseau et à déterminer les ressources matérielles dont vous avez besoin pour étendre cette capacité. Par exemple, si vous fournissez un service qui nécessite une quantité particulière de mémoire et que vous savez combien d’abonnés vous pouvez servir avec un ensemble donné de matériel, vous pouvez déterminer la quantité de mémoire dont vous avez besoin. Ou si vous souhaitez ajouter un service avec plus de mémoire par abonné, vous pouvez calculer le montant supplémentaire dont vous avez besoin, le comparer à la mémoire disponible et déterminer si vous devez provisionner de nouveaux ports, MIC, MPC ou routeurs pour gérer le nouveau service.

Limiter le nombre d’abonnés par type de client et par élément matériel avec le moniteur de ressources

En plus d’utiliser la surveillance des ressources pour surveiller et gérer l’utilisation de la mémoire système, vous pouvez l’utiliser pour limiter directement le nombre d’abonnés pris en charge par élément matériel : châssis, carte de ligne (MPC), MIC et port. Vous pouvez spécifier le nombre maximal d’abonnés pouvant être connectés à chacun de ces éléments. Vous appliquez la limite aux abonnés d’un seul type de client (DHCP, L2TP ou PPPoE) ou aux abonnés de l’un de ces types de clients. Dans ce dernier cas, la limite s’applique à la somme des sessions pour les trois types de clients.

La limitation des abonnés peut garantir que le nombre d’abonnés connectés par élément matériel ne dépasse pas le nombre que votre réseau peut servir avec stabilité à la bande passante de service souhaitée. Lorsque la limite est atteinte pour un élément matériel, les connexions des nouveaux abonnés sont refusées sur cet élément jusqu’à ce que le nombre d’abonnés passe en-dessous de la limite configurée. Les nouveaux abonnés au-dessus de la limite se connectent à un autre élément matériel du même domaine de diffusion. Lorsque vous configurez la limite sur une ou plusieurs jambes d’une interface Ethernet agrégée, la connexion est refusée si le nombre d’abonnés dépasse la valeur sur l’une des jambes.

Limiter les abonnés de cette façon répartit la charge entre les éléments matériels, mais ne fournit aucun type d’équilibrage de charge. Cette fonctionnalité peut également vous aider à cartographier la capacité de votre réseau et à déterminer les ressources matérielles dont vous avez besoin pour étendre cette capacité. Par exemple, si vous fournissez un service sur une bande passante particulière et que vous savez combien d’abonnés vous pouvez servir avec un ensemble donné de matériel, vous pouvez déterminer la quantité de bande passante dont vous avez besoin. Ou si vous souhaitez ajouter un service avec plus de bande passante par abonné, vous pouvez calculer la bande passante supplémentaire dont vous avez besoin, la comparer à votre bande passante disponible et déterminer si vous devez provisionner de nouveaux ports, MIC, MPC ou routeurs pour gérer le nouveau service.

Note:

La CLI utilise les termes fpc et pic. Pour cette fonctionnalité, fpc correspond à MPC et pic correspond à MIC.

Pour limiter le nombre maximal d’abonnés autorisés pour un élément matériel :

  1. Configurez le type de client pour les abonnés.
  2. (Facultatif) Configurez une limite d’abonnés sur le châssis.
  3. (Facultatif) Configurez une limite d’abonnés sur un MPC.
  4. (Facultatif) Configurez une limite d’abonnés sur un MIC.
  5. (Facultatif) Configurez une limite d’abonnés sur un port.

Par exemple, la configuration suivante définit des limites de châssis et de MPC pour les abonnés PPPoE :

Tableau de l’historique des versions
Libération
Description
17.4R1
À partir de la version 17.4R1 de Junos OS, des critères de classe de service (CoS) sont intégrés à la décision de limitation de l’accès des abonnés.
17.3R1
À partir de la version 17.3R1 de Junos OS, vous pouvez également utiliser la surveillance des ressources pour limiter directement le nombre d’abonnés pris en charge par élément matériel.