Dépannage des performances du système à l’aide de la méthodologie de surveillance des ressources

Surveillance des ressources et calcul de l’utilisation pour les cartes de ligne basées sur Trio

Dans les cartes de ligne basées sur Trio, les blocs de mémoire pour les filtres de saut suivant et de pare-feu sont alloués séparément. De plus, une mémoire d’extension est présente, qui est utilisée lorsque la mémoire allouée pour le filtre de saut suivant ou de pare-feu est entièrement consommée. Les filtres de saut suivant et de pare-feu peuvent allouer de la mémoire à partir de la mémoire d’extension. La région mémoire d’encapsulation est spécifique aux cartes de ligne basées sur une puce I et ne s’applique pas aux cartes de ligne basées sur Trio. Par conséquent, pour les cartes de ligne basées sur Trio, le pourcentage d’espace mémoire disponible peut être interprété comme suit :

% Free (NH) = (1- (Used NH memory + Used Expansion memory ) / (Total NH memory+Total Expansion memory)) × 100

% Free (Firewall or Filter) = (1-(Used FW memory+Used Expansion memory ) / (Total FW memory+Total Expansion memory)) × 100

La mémoire d’encapsulation est spécifique à la puce I et ne convient pas aux cartes de ligne basées sur Trio.

% Free (Encap memory) = Not applicable

Surveillance des ressources et calcul de l’utilisation pour les cartes de ligne basées sur I-Chip

Les cartes de ligne basées sur une puce contiennent 32 Mo de mémoire RAM statique (SRAM) associée au bloc de recherche de route et 16 Mo de mémoire SRAM associée au bloc WAN de sortie.

La mémoire de recherche de route est un pool unique de 32 Mo de mémoire divisé en deux segments de 16 Mo chacun. Dans une configuration standard, le segment 0 est utilisé pour NH et les préfixes, et le segment 1 est utilisé pour le pare-feu ou le filtre. Cette allocation peut être modifiée à l’aide de l’option route-memory-enhanced au niveau de la hiérarchie [edit chassis]. Dans une configuration générale, l’application NH peut se voir allouer de la mémoire à partir de l’un des deux segments. Par conséquent, le pourcentage de mémoire disponible pour NH est calculé sur 32 Mo de mémoire. Actuellement, la mémoire allouée aux applications de pare-feu provient uniquement du segment 1. Par conséquent, le pourcentage de mémoire libre à surveiller pour le pare-feu commence à partir des 16 Mo de mémoire disponibles dans le segment 1 uniquement.

Pour les cartes de ligne à puce I, le pourcentage d’espace mémoire disponible peut être interprété comme suit :

% Free (NH) = (32-(Used NH memory+Used FW memory+Used Other application)) / 32×100

% Free (Firewall or Filter)=(16-(Used NH memory+Used FW memory+Used Other application)) / 16×100

La taille de la mémoire pour la SRAM WAN de sortie (Iwo) est de 16 Mo et stocke les descripteurs de couche 2 qui contiennent les informations d’encapsulation. Cette entité est une ressource critique et doit être surveillée. Cet espace mémoire est affiché dans la sortie de la commande show sous la forme « Encap mem ». Le pourcentage de mémoire disponible pour la région d’encapsulation est calculé comme suit :

% Free (Encapsulation memory) = (16-(Iwo memory used ( L2 descriptors +other applications))) / 16×100

Le niveau de filigrane configuré pour la mémoire next-hop est également efficace pour la mémoire d’encapsulation. Par conséquent, si le pourcentage de mémoire disponible pour la région d’encapsulation tombe en dessous du filigrane configuré, des journaux sont générés.

Si le pourcentage de mémoire disponible est inférieur au filigrane de mémoire disponible d’un type de mémoire spécifique, le message d’erreur suivant est enregistré dans le syslog :

“Resource Monitor: FPC <slot no> PFE <pfe inst> <“JNH memory” or “FW/ Filter memory”> is below set watermark <configured watermark>”.

Vous pouvez configurer des opérations de suivi de surveillance des ressources à l’aide de l’instruction traceoptions file <filename> flag flag level level size bytes au niveau de la [edit system services resource-monitor] hiérarchie. Par défaut, les messages sont écrits au format /var/log/rsmonlog. Les journaux d’erreurs associés à l’échec de la communication de socket (entre le moteur de routage et le moteur de transfert de paquets) sont utiles pour diagnostiquer les problèmes de communication entre le moteur de routage et le moteur de transfert de paquets.

Du point de vue d’Ukern, MPC5E ne contient qu’une seule instance du moteur de transfert de paquets. La sortie de la commande show chassis fabric plane affiche l’état des connexions du plan de structure au moteur de transfert de paquets. Étant donné qu’il existe deux moteurs de transfert de paquets, vous remarquez PFE-0 et PFE-1 dans la sortie.

Étant donné qu’il n’existe qu’une seule instance du moteur de transfert de paquets pour MPC5E, la sortie de la commande show system resource-monitor fpc n’affiche qu’une seule ligne correspondant à l’instance 0 du moteur de transfert de paquets.

Le filigrane configuré est conservé dans les procédures GRES et ISSU unifiées.

Problème

Résolution