Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Surveillance du réseau à l’aide de SNMP

SUMMARY Cette section décrit l’implémentation SNMP dans Junos OS.

Understanding SNMP Implementation in Junos OS

SNMP Architecture

Une implémentation SNMP typique inclut trois composants:

  • Système de gestion du réseau (NMS): cette combinaison de matériel (équipements) et de logiciels (le gestionnaire SNMP) permet de surveiller et d’administrer un réseau. Le responsable enquête sur les équipements de votre réseau à quelle fréquence vous indiquez des informations sur la connectivité, l’activité et les événements du réseau.

  • Équipement géré: un équipement géré (également appelé élément réseau) est n’importe quel équipement sur un réseau géré par le NMS. Les routeurs et les commutateurs sont des exemples courants d’équipements gérés.

  • Agent SNMP: l’agent SNMP est le processus SNMP qui réside sur l’équipement géré et communique avec le système NMS. L’agent SNMP échange les informations de gestion du réseau avec le logiciel SNMP manager s’exécutant sur un NMS, ou un hôte. L’agent répond aux demandes d’informations et aux actions du responsable. L’agent contrôle également l’accès au réseau d’MIB, la collecte d’objets qui peuvent être vus ou modifiés par le gestionnaire SNMP.

Ce sujet contient les sections suivantes:

Bases de données MIB SNMP

Les données SNMP sont stockées dans un format hiérarchique hautement structuré, connu sous le nom de base d’informations de gestion (MIB). Une MIB définit les objets gérés dans un équipement réseau.

La MIB structure de base est basée sur une structure d’arborescence et définit un groupe d’objets dans des ensembles associés. Chaque objet du MIB est associé à un identifiant d’objet (OID), qui nomme l’objet. La « branche » de la structure d’arborescence est l’instance de l’objet géré, qui représente une ressource, un événement ou une activité au niveau de votre équipement réseau.

Les MIM sont soit standard, soit spécifiques à l’entreprise. Les MIM standard sont créées par Internet Engineering Task Force (IETF) et documentées dans diverses RFC. Selon le fournisseur, de nombreux MBIT standard sont livrés avec le logiciel NMS. Vous pouvez également télécharger les MIM standard à partir du site Web IETF,www.ietf.org, et les compiler dans votre NMS, si nécessaire.

Pour une liste de M MIB standard pris en charge, consultez les MB SNMPstandard soutenues par Junos OS .

Les MIM spécifiques aux entreprises sont développées et soutenues par un fabricant d’équipements spécifique. Si votre réseau contient des équipements MIM spécifiques à l’entreprise, vous devez les obtenir auprès du fabricant et les compiler dans votre logiciel de gestion réseau.

Pour une liste des M MIB pris en charge Juniper Networks’entreprise, consultez les MIM SNMP spécifiquesà l’entreprise Soutenues par Junos OS .

Authentification et communication avec le gestionnaire SNMP et l’agent

SNMP utilise une forme très basique d’authentification appelée chaînes de chaînes communautaires pour contrôler les accès entre un gestionnaire et des agents distants. Les chaînes de communautés sont des noms administratifs utilisés pour grouper les ensembles d’équipements (et les agents qui s’y exécutent) dans des domaines de gestion courants. Si un responsable et un agent partagent la même communauté, ils peuvent se parler entre eux. Beaucoup associent les chaînes de la communauté SNMP avec des mots de passe et des clés, car les tâches qu’elles font sont similaires. Ainsi, les communautés SNMP sont traditionnellement appelées chaînes.

La communication entre l’agent et le gestionnaire se fait sous l’un des formulaires suivants:

  • Get, et requêtes: le responsable demande des informations auprès de l’agent ; l’agent renvoie ces informations GetBulk dans un message de GetNextGet réponse.

  • Set requêtes: le gestionnaire modifie la valeur d’MIB objet contrôlé par l’agent ; l’agent indique l’état dans un Set message de réponse.

  • Traps notification: l’agent envoie des traps pour informer le responsable des événements importants se produisent sur l’équipement réseau.

Traps et informations SNMP

Les routeurs peuvent envoyer des notifications aux gestionnaires SNMP lorsque des événements importants se produisent sur un équipement réseau, le plus souvent des erreurs ou des défaillances. Vous pouvez envoyer des notifications SNMP en tant que traps ou en tant que requêtes informant. Les traps SNMP ne sont pas des notifications non confirmées. Les informations SNMP sont des notifications confirmées.

Les traps SNMP sont définis dans des M MIB standard ou spécifiques à l’entreprise. Les traps standard sont créés par les IETF et documentés dans diverses RFC. Les pièges standard sont compilés dans le logiciel de gestion du réseau. Vous pouvez également télécharger les pièges standard sur le site IETF Web, www.ietf.org.

Pour plus d’informations sur les traps standard pris en charge par le Junos OS, consultez les traps SNMPstandard pris en charge sur les équipements qui s’exécutent Junos OS .

Des pièges spécifiques à l’entreprise sont développés et pris en charge par un équipementier spécifique. Si votre réseau contient des équipements qui contiennent des pièges spécifiques à l’entreprise, vous devez les obtenir auprès du fabricant et les compiler dans votre logiciel de gestion réseau.

Pour plus d’informations sur les pièges d’entreprise pris en charge par le Junos OS, consultez Les traps SNMP spécifiquesà l’entreprise pris en charge par Junos OS . Pour plus d’informations sur les niveaux de gravité de la journalisation système pour les traps SNMP, Niveaux de gravité de la journalisation système pour les traps SNMP consultez.

À l’aide de pièges, le récepteur n’envoie aucune reconnaissance lorsqu’il reçoit un piège, et l’expéditeur ne peut déterminer si le piège a été reçu. Pour augmenter la fiabilité, les informations SNMP sont prise en charge dans SNMPv3. Un responsable SNMP qui reçoit un message d’information reconnaît le message par une réponse. Pour en savoir plus sur SNMP, consultez « Configuring SNMP Informs».

SNMP sur Junos OS

Sur Junos OS, SNMP utilise à la fois des normes (développées par IETF et documentées dans les RFC) et Juniper Networks MIM spécifiques à l’entreprise.

Remarque :

Par défaut, le SNMP n’est pas activé sur les équipements exécutant Junos OS.

Dans Junos OS, les processus qui conservent les données de gestion SNMP incluent les processus suivants:

  • Un agent SNMP maître qui réside sur l’équipement géré et qui est géré par le NMS, ou l’hôte.

    Le Junos OS agent SNMP se compose d’un agent principal SNMP (appelé processus SNMP, ou snmpd). Il réside sur l’équipement géré et est géré par le NMS ou l’hôte.

  • Divers sous-traitants qui résident sur différents modules de Junos OS, tels que le moteur de routage. L’agent SNMP maître délégue toutes les requêtes SNMP aux sous-traitants. Chaque sous-traitant est responsable de la prise en charge d’un ensemble spécifique de MIM.

  • Junos OS processus qui partagent des données avec les sous-traitants lors de l’enquête pour obtenir des données SNMP (par exemple, MIM liées aux interfaces).

La chaîne de communautés est le premier niveau d’authentification de gestion implémentée par l’agent SNMP dans Junos OS.

Pour plus d’informations, consultez les sections suivantes.

Junos OS de versions SNMP

Le Junos OS prend en charge les versions suivantes de SNMP:

  • SNMPv1: implémentation initiale de SNMP qui définit l’architecture et l’infrastructure de SNMP.

  • SNMPv2c: le protocole révisé, avec des améliorations des performances et des communications de responsable à responsable. En particulier, SNMPv2c met en œuvre des chaînes de communautés qui font sert de mot de passe pour déterminer qui, quoi et comment les clients SNMP peuvent accéder aux données dans l’agent SNMP. La chaîne de la communauté est contenue dans les requêtes et les listes GetGetBulk SNMP. GetNextSet L’agent peut avoir besoin d’une chaîne communautaire différente pour , et de requêtes (accès) que pour les GetGetBulk requêtes GetNextread-onlySetread-write (accès).

  • SNMPv3: le protocole le plus à jour est axé sur la sécurité. Le SNMPv3 définit un modèle de sécurité, un modèle de sécurité basé sur l’utilisateur (USM) et un modèle de contrôle d’accès basé sur la vue (VACM). L’USM SNMPv3 assure l’intégrité des données, l’authentification de l’origine des données, la protection en replay des messages et la protection contre la divulgation de la charge utile du message. Le SNMPv3 VACM fournit un contrôle d’accès afin de déterminer si un type spécifique d’accès (lire ou écrire) aux informations de gestion est autorisé.

En outre, le logiciel Junos OS agent SNMP accepte les adresses IPv4 et IPv6 pour le transport sur IPv4 et IPv6. Pour IPv6, la Junos OS prend en charge les fonctionnalités suivantes:

  • Données SNMP sur les réseaux IPv6

  • Données d’analyse spécifiques MIB IPv6

  • Agents SNMP pour IPv6

Niveaux de gravité de la journalisation système pour les traps SNMP

Pour certains pièges, lorsqu’une condition de trap est présente, indépendamment du fait que l’agent SNMP envoie un piège à un NMS, ce piège est consigné si la journalisation système est configurée pour journalisation d’un événement avec le niveau de gravité de la journalisation système.

Pour plus d’informations sur les niveaux de gravité de la journalisation système pour les traps standard, consultez les traps SNMPstandard pris en charge par Junos OS . Pour plus d’informations sur les niveaux de gravité de la journalisation système pour les pièges spécifiques à l’entreprise, consultez Les traps SNMP spécifiquesà l’entreprise pris en charge par Junos OS .

Flux de communication SNMP

Lorsqu’un NMS enquête sur l’agent principal pour les données, l’agent principal partage immédiatement les données avec le NMS si les données demandées sont disponibles auprès de l’agent principal ou de l’un des sous-traitants. Toutefois, si les données demandées n’appartiennent pas aux catégories qui sont maintenues par l’agent principal ou les sous-traitants, le sous-traitant sondage sond le noyau Junos OS ou le processus qui les tient à jour. Une fois qu’il reçoit les données requises, le sous-traitant transmet la réponse à l’agent principal, qui la transmet à son tour au NMS.

Figure 1 indique le flux de communication au sein du NMS, de l’agent principal SNMP (snmpd), des sous-traitants SNMP, du noyau Junos OS et du moteur de transfert de paquets.

Figure 1 : Flux de communication SNMPFlux de communication SNMP

Lorsqu’un événement important, le plus souvent une erreur ou une défaillance, se produit sur un équipement réseau, l’agent SNMP envoie des notifications au gestionnaire SNMP. L’implémentation SNMP dans Junos OS prend en charge deux types de notifications: pièges et informations. Les traps sont des notifications non confirmées, alors que les informations sont des notifications confirmées. Les informations sont uniquement prise en charge sur les équipements qui soutiennent la configuration SNMP version 3 (SNMPv3).

Trap File d’interrogation

Junos OS la trapuing permet d’éviter la perte des traps en raison de l’indisponibilité temporaire des routes. Deux types de files d’attente, files d’attente de destination et file d’attente d’étranglement sontcréés pour garantir la distribution de traps et pour contrôler le trafic piège.

Remarque :

Vous ne pouvez pas configurer la trap queueing dans Junos OS. Vous ne pouvez pas afficher d’informations sur les files d’attente de trap, à l’exception de ce qui est fourni dans les journaux système.

Junos OS forme une file d’attente de destination lorsqu’un piège vers une destination particulière est renvoyé car l’hôte n’est pas accessible, et ajoute les traps suivants à la même destination. Junos OS vérifie la disponibilité des routes toutes les 30 secondes et envoie les pièges de la file d’attente de destination de façon round-robin.

En cas d’échec du piège, le piège est ajouté à la file d’attente, le compteur de la tentative de distribution et le compteur de la prochaine tentative de distribution pour la file d’attente sont réinitialisés. Les tentatives suivantes se produisent à intervalles progressifs de 1 minute, 2 minutes, 4 minutes et 8 minutes. Le délai maximum entre les tentatives est de 8 minutes et le nombre maximal de tentatives est de 10. Après 10 tentatives infructueuses, la file d’attente de destination et tous les pièges dans la file d’attente sont supprimés.

Junos OS dispose également d’un mécanisme d’accélération pour contrôler le nombre de pièges (seuil de puissance ; valeur par défaut de 500 traps) envoyés pendant une période particulière (intervalle de vitesse ; intervalle de puissance de 5 secondes) et pour garantir la cohérence du trafic de pièges, en particulier lorsque de nombreux pièges sont générés à cause de changements d’état d’interface. L’intervalle de vitesse commence lorsque le premier piège arrive à l’accélérateur. Tous les pièges du seuil de trap sont traitées et les pièges qui dépassent cette limite sont mis en file d’attente.

La taille maximale des files d’attente de trap (c’est-à-dire la file d’attente de vitesse et la file d’attente de destination) est de 40 000. Toutefois, sur EX Series Commutateurs Ethernet, la taille maximale de la file d’attente de trap est de 1 000. La taille maximale d’une file d’attente est de 20 000 pour les équipements autres que EX Series commutateurs. Sur EX Series, la taille maximale d’une file d’attente est de 500. Lorsqu’un piège est ajouté à la file d’attente d’étranglement ou si la file d’attente de l’étranglement a dépassé la taille maximale, le piège est ajouté en haut de la file d’attente de destination, et toutes les tentatives suivantes de la file d’attente de destination sont interrompues pendant une période de 30 secondes, après quoi la file d’attente de destination redémarre les traps.

Remarque :

Les utilisateurs ne peuvent pas configurer la configuration Junos OS pour la trap file d’file d’file d’utilisateur. Les utilisateurs ne peuvent pas afficher d’informations sur les files d’attente de trap, sauf ce qui est disponible dans les informations consignées.

Présentation du SNMPv3

Contrairement aux versions 1 (SNMPv1) et SNMP version 2 (SNMPv2), SNMP version 3 (SNMPv3) prend en charge l’authentification et le chiffrement. Le SNMPv3 utilise le modèle de sécurité basé sur l’utilisateur (USM) pour la sécurité des messages et le modèle de contrôle d’accès basé sur la vue (VACM) pour le contrôle des accès. USM spécifie l’authentification et le chiffrement. VACM spécifie des règles de contrôle d’accès.

USM utilise le concept d’utilisateur pour lequel les paramètres de sécurité (niveaux de sécurité, d’authentification, de protocoles de confidentialité et clés) sont configurés pour l’agent et le gestionnaire. Les messages envoyés via USM sont mieux protégés que les messages envoyés avec des chaînes de communautés, où les mots de passe sont envoyés en clair. Avec USM, les messages échangés entre le gestionnaire et l’agent peuvent faire l’effet d’une vérification de l’intégrité des données et d’une authentification de leur origine. USM se protège contre les retards de messages et les rejeu de messages en utilisant des indicateurs de temps et des demandes d’ID. Le chiffrement est également disponible.

Pour compléter l’USM, le SNMPv3 utilise VACM, un modèle de contrôle d’accès hautement granulaire pour les applications SNMPv3. En se basant sur le concept d’application de stratégies de sécurité au nom des groupes qui interrogent l’agent, l’agent décide si le groupe est autorisé à afficher ou à modifier des objets MIB données spécifiques. VACM définit les ensembles de données (appelés vues), les groupes d’utilisateurs de données et les déclarations d’accès qui définissent la façon dont un groupe particulier d’utilisateurs peut utiliser pour la lecture, l’écriture ou la réception de pièges.

Trap les entrées dans SNMPv3 sont créées en configurant l’alerte, le filtre d’alerte, l’adresse cible et les paramètres de cible. notifyL’instruction spécifie le type de notification (trap) et contient une balise unique. La balise définit un ensemble d’adresses cibles pour recevoir un piège. Le filtre notifié définit l’accès à un ensemble d’identifiants d’objets pièges (OIDs). L’adresse cible définit l’adresse d’une application de gestion et d’autres attributs à utiliser pour envoyer des notifications. Les paramètres cibles définissent le traitement des messages et les paramètres de sécurité à utiliser pour envoyer des notifications à une cible de gestion particulière.

Pour configurer le SNMPv3, exécutez les tâches suivantes:

Présentation du SNMPv3 (QFX en mode autonome)

Le QFX3500 prend en charge la version 3 de SNMP (SNMPv3). Le SNMPv3 améliore les fonctionnalités des SNMPv1 et SNMPv2c en prise en charge de l’authentification des utilisateurs et du chiffrement des données. SNMPv3 utilise le modèle de sécurité basé sur l’utilisateur (USM) pour assurer la sécurité des messages SNMP, ainsi que le modèle de contrôle d’accès basé sur la vue (VACM) pour le contrôle des accès des utilisateurs.

Les fonctionnalités de SNMPv3 sont les suivantes:

  • Grâce à USM, les messages SNMP entre le gestionnaire SNMP et l’agent peuvent faire authentifier la source du message et contrôler l’intégrité des données. USM réduit les retards de messagerie et les rejeu de messages en appliquant les délais d’attente et en contrôlant les ID de demande de message en double.

  • VACM vient compléter l’USM en fournissant à l’agent un contrôle d’accès utilisateur pour les requêtes SNMP. Vous définissez les droits d’accès que vous souhaitez étendre à un groupe d’un ou plusieurs utilisateurs. Les privilèges d’accès sont déterminés par les paramètres du modèle de sécurité ( ou ) et les paramètres du niveau de sécurité usmv1 ( , ou v2authenticationprivacynone ). Pour chaque niveau de sécurité, vous devez associer MIB vue du groupe. L’association d’MIB avec un groupe autorise la lecture, l’écriture MIB un ensemble d’objets de ce groupe.

  • Vous configurez les paramètres de sécurité pour chaque utilisateur, notamment le nom d’utilisateur, le type d’authentification et le mot de passe d’authentification, ainsi que le type de confidentialité et le mot de passe de confidentialité. Le nom d’utilisateur donné à chaque utilisateur se trouve dans un format qui dépend du modèle de sécurité configuré pour cet utilisateur.

  • Pour assurer la sécurité de la messagerie, un autre type de nom d’utilisateur, appelé nom de sécurité, est inclus dans les données de messagerie envoyées entre le serveur SNMP local et le serveur SNMP de destination. Chaque nom d’utilisateur est maché sur un nom de sécurité, mais le nom de sécurité est dans un format indépendant du modèle de sécurité.

  • Trap les entrées dans SNMPv3 sont créées en configurant l’alerte, le filtre d’alerte, l’adresse cible et les paramètres de cible. L’instruction spécifie le type de notification (trap) et contient une balise unique qui définit un ensemble d’adresses cibles notify pour recevoir un piège. Le filtre notifié définit l’accès à un ensemble d’identifiants d’objets pièges (OIDs). L’adresse cible définit l’adresse d’une application de gestion SNMP et d’autres attributs utilisés pour l’envoi de notifications. Les paramètres de cible définissent le traitement des messages et les paramètres de sécurité utilisés pour l’envoi de notifications à une cible particulière.

Chargement MIB fichiers sur un système de gestion réseau

Pour que votre système de gestion réseau (NMS) identifie et comprenne les objets MIB utilisés par le Junos OS, vous devez d’abord charger les fichiers MIB sur votre NMS à l’aide d’un compilateur MIB réseau. Un MIB de données est un service public qui analyse les informations MIB telles que le nom de l’objet MIB, les ID et le type de données pour le NMS.

Vous pouvez télécharger le package Junos MIB de l’indice MBS Junos OS Enterprise à l’https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html . Le package Junos MIB est disponible dans .zip et .tar sous emballages. Vous pouvez télécharger le format approprié en fonction de vos besoins.

Le package Junos MIB contient deux dossiers: StandardMibs et JuniperMibs . Le dossier contient les MPC et RFC standard qui sont pris en charge sur les équipements exécutant le Junos OS, alors que le dossier contient les MIM de StandardMibsJuniperMibs Juniper Networks’entreprise spécifiques.

Pour charger MIB fichiers nécessaires à la gestion et à la surveillance des équipements exécutant les Junos OS:

  1. Allez sur la page SNMP MIB Explorer Télécharger la page pour Juniper Networks packages de MIBSNMP ( SNMP MIB Explorer).
  2. Cliquez sur le ou le lien dans le titre de version approprié pour télécharger le package MIB TARZIP Junos pour cette version.
  3. Décompressez le fichier .tar.zip (ou) en utilisant un service public approprié.
  4. Chargez les fichiers MIB standard (dans le StandardMibs dossier) dans l’ordre suivant:
    Remarque :

    Certains des compilateurs MIB couramment utilisés sont préchargés sur des MIM standard. Si les MIM standard sont déjà chargés sur le compilateur MIB que vous utilisez, passez à cette étape et passez à l’étape 7.

    1. mib-SNMPv2-SMI.txt

    2. mib-SNMPv2-TC.txt

    3. mib-IANAifType-MIB.txt

    4. mib-IANA-RTPROTO-MIB.txt

    5. mib-rfc1907.txt

    6. mib-rfc4293.txt

    7. mib-rfc2012a.txt

    8. mib-rfc2013a.txt

    9. mib-rfc2863a.txt

  5. Chargez les fichiers standards restants MIB de données.
    Remarque :

    Vous devez suivre l’ordre spécifié dans cette procédure et vous assurer que toutes les MIM standard sont chargées avant de charger les MIM spécifiques à l’entreprise. Certaines dépendances peuvent nécessiter la présence d’une MIB sur le compilateur avant de charger d’autres MIB. Vous pouvez trouver ces dépendances répertoriées dans la section du MIB IMPORT fichier.

  6. Chargez les Juniper Networks MIM S MIB MI spécifiques à l’entreprise et les MIM SMI en option suivantes en fonction mib-jnx-smi.txt de vos besoins:
    • mib-jnx-js-smi.txt—(Facultatif) Pour les objets Juniper Security MIB tree

    • mib-jnx-ex-smi.txt—(Facultatif) pour les EX Series Commutateurs Ethernet

    • mib-jnx-exp.txt—(Recommandé) Pour l’Juniper Networks des objets MIB la recherche d’objets

  7. Chargez les MIM de l’entreprise restantes dans le JuniperMibs dossier.
Conseil :

Lors du chargement d’un fichier MIB, si le compilateur renvoie un message d’erreur en disant que l’un des objets n’est pas indéfini, ouvrez le fichier MIB à l’aide d’un éditeur de texte et veillez à ce que tous les fichiers MIB répertoriés dans la section soient chargés sur le IMPORT compilateur. Si l’un des fichiers MIB répertoriés dans la section n’est pas chargé sur le compilateur, chargez ce fichier MIB, puis essayez de charger le fichier MIB qui n’a pas été IMPORT chargé.

Par exemple, le ping d’entreprise MIB, a des dépendances sur mib-jnx-ping.txt RFC 2925, DiSMAN-PING-MIB, mib-rfc2925a.txt . Si vous tentez de charger avant de charger, le compilateur renvoie un message d’erreur en disant que certains objets ne sont pas mib-jnx-ping.txtmib-rfc2925a.txt encore mib-jnx-ping.txt définies. charger, mib-rfc2925a.txt puis essayer de mib-jnx-ping.txt charger. Le ping spécifique à l’entreprise mib-jnx-ping.txt MIB, puis charge sans aucun problème.

afficher snmp

Plusieurs commandes accessibles en mode opérationnel Junos OS pour surveiller les informations SNMP. Voici quelques-unes des commandes:

  • show snmp health-monitor, qui affiche le journal et les informations d’alarme du moniteur d’état.

  • show snmp mib, qui affiche les informations des MB, telles que les informations sur les équipements et le système.

  • show snmp statistics, qui affiche les statistiques SNMP, telles que le nombre de paquets, les baisses silencieuses et les valeurs de sortie non valides.

  • show snmp rmon, qui affiche l’alarme RMON, l’événement, l’historique et les informations de journal

L’exemple suivant fournit un exemple de sortie à partir de la show snmp health-monitor commande:

L’exemple suivant fournit un exemple de sortie à partir de la show snmp mib commande:

L’exemple suivant fournit un exemple de sortie à partir de la show snmp statistics commande:

Junos OS de la FAQ sur SNMP

Ce document présente les questions les plus fréquentes concernant les fonctionnalités et technologies utilisées pour implémenter des services SNMP sur Juniper Networks périphériques utilisant le Système d’exploitation Junos.

SNMP permet aux utilisateurs de surveiller les équipements réseau depuis un emplacement central. De nombreux systèmes de gestion réseau (NMS) sont basés sur SNMP et la prise en charge de ce protocole est une fonctionnalité clé de la plupart des équipements réseau.

Juniper Networks fournit de nombreuses plates-formes différentes qui soutiennent SNMP sur le Junos OS. La Junos OS inclut un agent SNMP intégré qui fournit aux applications de gestion à distance un accès à des informations détaillées sur les équipements du réseau.

Une implémentation SNMP typique se présente sous trois formes:

  • Équipements gérés, comme les routeurs et les commutateurs.

  • Agent SNMP: processus qui réside sur un équipement géré et communique avec le NMS.

  • NMS – Aaa de matériels et de logiciels utilisés pour surveiller et gérer le réseau ; qui exécute le logiciel SNMP manager. Également appelé gestionnaire SNMP.

L’agent SNMP échange les informations de gestion du réseau avec le gestionnaire SNMP (NMS). L’agent répond aux demandes d’informations et aux actions du responsable. Le gestionnaire SNMP collecte des informations sur la connectivité, l’activité et les événements du réseau en sondant les équipements gérés.

L’implémentation SNMP dans le Junos OS utilise un agent SNMP maître (appelé processus SNMP ou snmpd) qui réside sur l’équipement géré. Divers sous-traitants résident sur différents modules du Junos OS (tels que les moteur de routage) et ces sous-traitants sont gérés par le snmpd.

Junos OS FAQ sur SNMP

Cette présentation de la technologie , souvent posées et posées, aborde les aspects liés à SNMP:

Junos OS FAQ sur la prise en charge de SNMP

Cette section présente des questions et réponses fréquentes associées à la prise en charge de SNMP Junos OS.

Which SNMP versions does Junos OS support?

Junos OS prend en charge SNMP version 1 (SNMPv1), la version 2 (SNMPv2c) et la version 3 (SNMPv3). Par défaut, la fonction SNMP est désactivée sur Juniper Networks périphérique.

Which ports (sockets) does SNMP use?

Le port par défaut pour les requêtes SNMP est le port 161. Le port par défaut des traps et informations SNMP est le port 162. Le port utilisé pour les traps et informations SNMP est configurable, et vous pouvez configurer votre système pour utiliser des ports autres que le port 162 par défaut. Toutefois, le port d’écoute SNMP reste le même ; cette fonction est établie sur la RFC.

Is SNMP support different among the Junos OS platforms?

Non, la prise en charge de SNMP ne se fait pas de la même manière Junos OS plates-formes d’Junos OS réseau. La configuration, l’interaction et le comportement SNMP sont les mêmes sur n’importe Junos OS périphérique. La seule différence qui peut se produire entre les plates-formes est MIB la prise en charge.

Consultez également SNMP MIB Explorer pour obtenir une liste de M MIB pris en charge sur les plates-Junos OS réseau.

Does Junos OS support the user-based security model (USM)?

Oui, Junos OS USM dans le cadre de sa prise en charge du SNMPv3. SNMPv3 contient davantage de mesures de sécurité que les versions précédentes de SNMP, y compris la fourniture d’un USM défini. L’USM SNMPv3 assure la sécurité des messages via l’intégrité des données, l’authentification de l’origine des données, la protection en replay du message et la protection contre la divulgation de la charge utile du message.

Does Junos OS support the view-based access control model (VACM)?

Oui, Junos OS vaCM dans le cadre de sa prise en charge du SNMPv3. SNMPv3 contient davantage de mesures de sécurité que les versions précédentes de SNMP, y compris la fourniture d’un VACM défini. Le SNMPv3 VACM détermine si un type spécifique d’accès (lire ou écrire) aux informations de gestion est autorisé.

Does Junos OS support SNMP informs?

Oui, Junos OS SNMP est informé dans le cadre de sa prise en charge de SNMPv3. Les informations SNMP sont des notifications confirmées envoyées par des agents SNMP aux gestionnaires SNMP en cas d’événements importants sur un équipement réseau. Lorsqu’un responsable SNMP reçoit une information, il envoie une réponse à l’expéditeur pour vérifier la réception de l’information.

Can I provision or configure a device using SNMP on Junos OS?

Non, le provisionnement ou la configuration d’un équipement utilisant SNMP n’est pas autorisé Junos OS.

JUNOS OS FAQ sur les MIM

Cette section contient des questions et réponses fréquentes liées aux MIM Junos OS imposent fréquemment.

What is a MIB?

Une base d’informations de gestion (MIB) est un tableau des définitions des objets gérés d’un équipement réseau. Les MIM sont utilisées par SNMP pour conserver des définitions standard de tous les composants et de leurs conditions d’exploitation au sein d’un équipement réseau. Chaque objet du MIB possède un code d’identification appelé identificateur d’objet (OID).

Les MIM sont soit standard, soit spécifiques à l’entreprise. Les MIM standard sont créées par Internet Engineering Task Force (IETF) et documentées dans diverses RFC. Les MIM spécifiques aux entreprises sont développées et soutenues par un fabricant d’équipements spécifique.

Pour obtenir une liste de M MIB standard pris en charge, consultez les MIM standard SNMP soutenues par Junos OS.

Pour une liste des M MIB spécifiques Juniper Networks’entreprise, consultez les MIM SNMP spécifiquesà l’entreprise Soutenues par Junos OS .

Do MIB files reside on the Junos OS devices?

Non, les MIB de sécurité ne sont pas sur les Junos OS périphériques. Vous devez télécharger les fichiers MIB de la page des publications Juniper Networks pour obtenir la version Junos OS requise: https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html .

How do I compile and load the Junos OS MIBs onto an SNMP manager or NMS?

Pour que vos systèmes de gestion réseau (NMS) identifient et comprennent les objets MIB utilisés par Junos OS, vous devez d’abord charger les fichiers MIB sur votre NMS à l’aide d’un compilateur MIB réseau. Un MIB compilateur de données est un outil d’analyse des informations MIB, telles que les noms d’objet, les ID et les types de données du NMS de MIB.

Vous pouvez télécharger le package de Junos OS MIB à partir de la section MBs et Traps spécifiques à l’entreprise à l’https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html ouà https://www.juniper.net/documentation/software/junos/index.html.

Le package Junos OS MIB dossiers comprend deux dossiers: StandardMibs, contenant les MIM standard pris en charge sur Juniper Networks et, contenant Juniper Networks JuniperMibs MIM spécifiques à l’entreprise. Avant de télécharger des MIM spécifiques à l’entreprise, vous devez télécharger et décompresser les MIM standard requis. Certaines dépendances peuvent nécessiter la présence d’une MIB standard particulière sur le compilateur avant de charger une MIB spécifique à l’MIB.

Le package Junos OS MIB formats est .zip.tar disponible. Téléchargez le format adapté à vos besoins.

Utilisez les étapes suivantes pour charger des MIB pour les équipements qui s’exécutent Junos OS:

  1. Accédez à la page de téléchargement Juniper Networks appropriée et localisez le Enterprise MIBs lien dans la Enterprise-Specific MIBs and Traps section.

    Remarque :

    Bien que le lien soit intitulé , les MIM standard et les MIM spécifiques à l’entreprise peuvent être Enterprise MIBs téléchargés à partir de cet emplacement.

  2. Cliquez sur TAR le ou le lien pour télécharger le Junos OS MIB ZIP package.

  3. Décompressez le fichier .tar.zip (ou) en utilisant un service public approprié.

    Remarque :

    Certains compilateurs de MIB standard sont préchargés sur des MIM standard. Vous pouvez ignorer l’étape et l’étape et passer à l’étape si les MIM standard sont déjà 456 chargés sur votre système.

  4. Chargez les fichiers standards MIB dans le StandardMibs dossier.

    Charger les fichiers dans l’ordre suivant:

    1. mib-SNMPv2-SMI.txt

    2. mib-SNMPv2-TC.txt

    3. mib-IANAifType-MIB.txt

    4. mib-IANA-RTPROTO-MIB.txt

    5. mib-rfc1907.txt

    6. mib-rfc2011a.txt

    7. mib-rfc2012a.txt

    8. mib-rfc2013a.txt

    9. mib-rfc2863a.txt

  5. Chargez les fichiers standard restants MIB données.

    Remarque :

    Vous devez suivre l’ordre spécifié dans cette procédure et vous assurer que toutes les MIM standard sont chargées avant de charger les MIM spécifiques à l’entreprise. Certaines dépendances peuvent nécessiter la présence d’une MIB standard particulière sur le compilateur avant de charger une MIB spécifique à l’MIB. Les dépendances sont répertoriées dans la IMPORT section du MIB fichier.

  6. Après chargement des MIM standard, chargez le pare-Juniper Networks SMI spécifique à l’entreprise MIB, et les MIM SMI en option suivantes en fonction de mib-jnx-smi.txt vos besoins:

    • mib-jnx-exp.txt—(Recommandé) pour l’Juniper Networks et MIB-phase

    • mib-jnx-js-smi.txt— (en option) pour les objets Juniper Security MIB Tree

    • mib-jnx-ex-smi.txt —(facultatif) pour EX Series Commutateurs Ethernet

  7. Charger tous les MIM souhaités en rapport avec l’entreprise dans le JuniperMibs dossier.

    Conseil :

    Lors du chargement d’un fichier MIB, si le compilateur renvoie un message d’erreur indiquant que l’un des objets n’est pas indéfini, ouvrez le fichier MIB à l’aide d’un éditeur de texte et veillez à ce que tous les fichiers MIB répertoriés dans la section soient chargés sur le IMPORT compilateur. Si l’un des fichiers MIB répertoriés dans la section ne sont pas chargés sur le compilateur, chargez d’abord le fichier ou les fichiers manquants, alors essayez de charger le fichier MIB IMPORT échec.

    Le système peut renvoyer une erreur si les fichiers ne sont pas chargés dans un ordre particulier.

What is SMI?

La structure de la version informations de gestion (SMI) est un sous-ensemble de la notation de syntaxe abstraite (ASN.1), qui décrit la structure des objets. Il s’agit de la syntaxe de notation, ou « grammaire », qui est la norme pour l’écriture de mibs.

Which versions of SMI does Junos OS support?

La Junos OS prend en charge SMIv1 pour les MB SNMPv1 et SMIv2 pour SNMPv2c et les MIM d’entreprise.

Does Junos OS support MIB II?

Oui, Junos OS prend MIB II, la deuxième version de la MIB standard.

Les fonctionnalités de MIB II sont les suivantes:

  • Des ajouts qui reflètent de nouvelles exigences opérationnelles.

  • Rétrocompatibilité avec les MBIT et SNMP d’origine.

  • Prise en charge améliorée des entités multiprotocoles.

  • Meilleure lecture.

Reportez-vous à la documentation de mise à jour pertinente pour obtenir une liste des M MIB pris en charge. Allez sur « https://www.juniper.net/documentation/software/junos/index.html ».

Are the same MIBs supported across all Juniper Networks devices?

Tous les équipements de Junos OS, tels que l’interface MIB (ifTable), la MIB système et le châssis MIB. Certains MIM ne sont pris en charge que par des fonctionnalités sur des plates-formes spécifiques. Par exemple, la passerelle de MIB pont est prise en charge par le EX Series Commutateurs Ethernet et les passerelles SRX Series services pour la filiale.

What is the system object identifier (SYSOID) of a device? How do I determine the SYSOID of my device?

Le modèle jnx-chas (Chassis Definitions for Router Model) possède une MIB pour chaque jnxProductName Junos OS réseau. L’ID de l’objet système d’un équipement est identique à l’ID de l’objet de jnxProductName la plate-forme. Par exemple, pour un routeur de périphérie multiservice M7i, jnxProductNameM7i est 1.3.6.1.4.1.2636.1.1.1.2.10 dans la filiale de jnxProductName, identique à la SYSOID du M7i (.1.3.6.1.4.1.2636.1.1.1.2.10).

How can I determine if a MIB is supported on a platform? How can I determine which MIBs are supported by a device?

La prise en charge des équipements et des plates-formes MBIT est répertoriée dans la Junos OS documentation technique. Voir les MIM SNMP spécifiques à l’entreprise Prise en charge par les MIM Junos OS et standard SNMP Soutenues par des documents Junos OS pour afficher la liste des MIM et des équipements Junos OS pris en charge.

What can I do if the MIB OID query is not responding?

Il peut y avoir différentes raisons pour lesquelles la MIB OID cesse de répondre. L’une des raisons est que le MIB lui-même n’a aucune réponse. Pour vérifier que l’MIB répond, utilisez la show snmp mib walk | get MIB name | MIB OID commande:

  • Si le MIB répond, le problème de communication existe entre l’agent principal SNMP et l’agent SNMP. Les raisons possibles de ce problème incluent des problèmes de réseau, une configuration de communauté incorrecte, une configuration SNMP incorrecte, etc.

  • Si le MIB répond pas, activez les PDUS et les erreurs dans le traceoptions SNMP. Tous les PDUs SNMP entrants et sortants sont enregistrés. Vérifiez la traceoptions sortie pour voir s’il y a des erreurs.

Si la requête OID vous MIB problème, l’assistance technique des produits est disponible par l’intermédiaire Juniper Networks centre d’assistance technique de l’assistance technique (JTAC).

What is the enterprise branch number for Junos OS?

Le nombre de filiales d’entreprise Junos OS 2636. Les numéros de filiales d’entreprise sont utilisés dans MIB configurations SNMP, et sont également connus sous le nom de codes de gestion de réseau SMI pour l’entreprise privée.

Which MIB displays the hardware and chassis details on a Juniper Networks device?

Le châssis MIB (jnxchassis.mib) affiche les détails du matériel et du châssis pour chaque Juniper Networks périphérique. Il fournit des informations sur le routeur et ses composants. Le châssis MIB’état de chaque composant.

Which MIB objects can I query to determine the CPU and memory utilization of the Routing Engine, Flexible PIC Concentrator (FPC), and PIC components on a device?

Interrogez le châssis MIB objets , et pour découvrir l’utilisation du processeur et de la mémoire des jnxOperatingMemoryjnxOperatingtBufferjnxOperatingCPU composants matériels d’un équipement.

Is the interface index (ifIndex) persistent?

L’ifIndex est persistant lors des redémarrages si la version Junos OS reste la même, ce qui signifie que les valeurs attribuées aux interfaces dans l’ifIndex ne changent pas.

En cas de mise à niveau logicielle, l’équipement tente de maintenir la persistance de l’ifIndex au mieux. Pour Junos OS version 10.0 et antérieure, l’ifIndex n’est pas persistant lorsqu’une mise à niveau logicielle est mise à niveau vers Junos OS version 10.1 et ultérieure.

Is it possible to set the ifAdminStatus?

SNMP n’est pas autorisé à définir l’ifAdminStatus.

Which MIB objects support SNMP set operations?

Les Junos OS opérations définies par SNMP sont prise en charge dans les tables et variables MIB suivantes:

  • snmpCommunityTable

  • événementTable

  • alarmTable

  • snmpTargetAddrExtTable

  • jnxPingCtlTable

  • pingCtlTable

  • traceRouteCtlTable

  • jnxTraceRouteCtlTable

  • sysContact.0

  • sysName.0

  • sysLocation.0

  • pingMaxConcurrentRequests.0

  • traceRouteMaxConcurrentRequests.0

  • usmUserSpinLock

  • usmUserOwnAuthKeyChange

  • usmUserPublic

  • vacmSecurityToGroupTable (vacmGroupName, vacmSecurityToGroupStorageType et vacmSecurityToGroupStatus)

  • vacmAccessTable (vacmAccessContextMatch, vacmAccessReadViewName, vacmAccessWriteViewName, vacmAccessNotifyViewName, vacmAccessStorageType et vacmAccessStatus)

  • vacmViewSpinLock

  • vacmViewTreeFamilyTable (vacmViewTreeFamilyMask, vacmViewTreeFamilyType, vacmViewTreeFamilyStorageType et vacmViewTreeFamilyStatus)

Does Junos OS support remote monitoring (RMON)?

Oui, la Junos OS RMON telle que définie dans le RFC 2819, la surveillance de réseau à distance base d’informations de gestion. Toutefois, la surveillance à distance de la version 2 (RMON 2) n’est pas prise en charge.

Can I use SNMP to determine the health of the processes running on the Routing Engine?

Oui, vous pouvez utiliser SNMP pour déterminer l’état des moteur de routage en configurant la fonctionnalité de surveillance de l’état. Sur Juniper Networks réseau, les alarmes et les événements RMON fournissent une grande partie de l’infrastructure nécessaire pour réduire les coûts d’interrogation des NMS. Cependant, vous devez configurer le NMS pour configurer des objets spécifiques MIB dans des alarmes RMON. Cette situation exige souvent une expertise spécifique aux équipements et la personnalisation de l’application de surveillance. En outre, certaines MIB d’objets qui ont besoin d’être gérées ne sont définies qu’au moment de l’initialisation, ou qui changent au moment du MIB ne peuvent pas être configurées à l’avance.

Pour résoudre ces problèmes, le moniteur d’état étend l’infrastructure d’alarme RMON pour fournir une surveillance prédéfinie d’un ensemble d’instances d’objets, telles que l’utilisation du système de fichiers, l’utilisation du processeur et l’utilisation de la mémoire. Il comprend également la prise en charge d’instances d’objets dynamiques ou inconnues, telles que les processus logiciels Junos OS.

Pour afficher la configuration de surveillance de l’état, utilisez la show snmp health-monitor commande:

Lorsque vous configurez le moniteur d’état, des informations de surveillance pour certaines instances d’objet sont disponibles, comme indiqué dans Tableau 1 .

Tableau 1 : Instances d’objets surveillés

Objet

Description

jnxHStoragePercenter.1

Surveille le système de fichiers suivant sur le routeur ou le commutateur: /dev/ad0s1a:

Il s’agit du système de fichiers racines monté sur / .

jnxHrStoragePercentused.2

Surveille le système de fichiers suivant sur le routeur ou le commutateur: /dev/ad0s1e:

Il s’agit de la configuration du système de fichiers sur /config .

jnxOperatingCPU (RE0)

Surveillez l’utilisation du processeur pour les moteurs de routage RE0 et RE1. Les valeurs d’index attribuées aux moteurs de routage dépendent de la MIB de châssis qui utilise un modèle d’index zéro ou un modèle d’indexation basé sur un seul. Le schéma d’indexation étant configurable, l’index correct est déterminé chaque fois que le routeur est initialisé et qu’une modification de la configuration est constaté. Si le routeur ou le commutateur ne dispose que d’une moteur de routage, la surveillance de l’entrée d’alarme du re1 est supprimée après cinq tentatives inf échec pour obtenir la valeur du processeur.

jnxOperatingCPU (RE1)

jnxOperatingBuffer (RE0)

Surveillez la quantité de mémoire disponible sur les moteurs de routage RE0 et RE1. Étant donné que l’indexation de cet objet est identique à celle de jnxOperatingCPU, les valeurs de l’index sont modifiées en fonction du schéma d’indexation utilisé dans le MIB Chassis. Comme pour le processeur jnxOperatingCPU, la surveillance de l’entrée d’alarme (RE1) est supprimée si le routeur ou le commutateur ne dispose que d’moteur de routage.

jnxOperatingBuffer (RE1)

sysApplEllomrunCPU

Surveille l’utilisation du processeur pour chaque Junos OS du logiciel. Plusieurs instances d’un même processus sont contrôlées et indexées séparément.

sysApplEllomrunMemory

Surveille l’utilisation de la mémoire pour chaque Junos OS logiciels. Plusieurs instances d’un même processus sont contrôlées et indexées séparément.

Les entrées de journal système générées pour tous les événements de surveillance d’état, tels que les seuils franchis et les erreurs, ont une balise correspondante plutôt HEALTHMONITOR qu’une SNMPD_RMON_EVENTLOG balise générique. Cependant, le moniteur d’état envoie un RMON et risingThresholdfallingThreshold des traps génériques.

Are the Ping MIBs returned in decimal notation and ASCII?

Oui, la notation décimale et l’ASCII sont pris en charge, ce qui est l’implémentation standard dans SNMP. Toutes les chaînes sont encodees ASCII.

L’exemple suivant affiche le ping MIB notation hexadécimale:

Cela se traduit par ASCII:

À partir Junos OS version 9.6 et ultérieure, le pare-Junos OS CLI valeurs ASCII à l’aide de la commande show snmp mib get | get-next | walk ascii .

L’exemple suivant affiche la sortie avec l’option ASCII:

L’exemple suivant affiche la sortie sans l’option ASCII:

Vous pouvez convertir les valeurs DÉCimales et ASCII à l’aide d’un graphique ASCII décimal de la même http://www.asciichart.com.

Is IPv6 supported by the Ping MIB for remote operations?

Non, IPv6 n’est pas pris en charge.

Is there an SNMP MIB to show Address Resolution Protocol (ARP) table information? Are both IP and MAC addresses displayed in the same table?

Oui, la Junos OS prend en charge la norme MIB , décrite dans le ipNetToMediaTable RFC 2011, SNMPv2 base d’informations de gestion pour leprotocole Internet utilisant SMIv2 . Ce tableau permet de mappage des adresses IP avec leurs adresses MAC correspondantes.

JUNOS OS de configuration SNMP

Cette section présente des questions et réponses fréquentes associées à Junos OS configuration SNMP.

Can the Junos OS be configured for SNMPv1 and SNMPv3 simultaneously?

Oui, SNMP présente une rétrocompatibilité, ce qui signifie que les trois versions peuvent être activées simultanément.

Can I filter specific SNMP queries on a device?

Oui, vous pouvez filtrer des requêtes SNMP spécifiques sur un équipement à l’aide de excludeinclude déclarations.

L’exemple suivant illustre une configuration qui bloque les opérations de lecture et d’écriture sur tous les OID sous .1.3.6.1.2.1.1 pour la test communauté:

Can I change the SNMP agent engine ID?

Oui, l’ID du moteur d’agent SNMP peut être modifié en adresse MAC de l’équipement, en adresse IP de l’équipement ou en toute autre valeur souhaitée. Plusieurs exemples sont inclus ici.

L’exemple suivant indique comment utiliser l’adresse MAC d’un équipement en tant qu’ID de moteur d’agent SNMP:

L’exemple suivant indique comment utiliser l’adresse IP d’un équipement en tant qu’ID de moteur d’agent SNMP:

L’exemple suivant illustre l’utilisation d’une valeur sélectionnée, dans ce cas, en tant qu’ID de moteur AA d’agent SNMP d’un équipement:

How can I configure a device with dual Routing Engines or a chassis cluster (SRX Series Services Gateways) for continued communication during a switchover?

Lors de la configuration pour une communication continue, la configuration SNMP doit être identique entre les moteurs de routage. Cependant, il est préférable d’avoir des moteur de routage d’accès distincts configurés pour chaque moteur de routage, en particulier lorsque vous utilisez SNMPv3.

L’exemple suivant illustre la configuration des moteurs de routage dans un moteur de routage double. Notez que les moteur de routage sont placés sur les adresses MAC pour chaque moteur de routage:

Voici un exemple de configuration SNMPv3 sur un équipement moteur de routage double écran:

How can I track SNMP activities?

SNMP trace l’activité des agents SNMP et enregistre les informations dans les fichiers journaux.

Voici traceoptions peut-être un exemple de configuration:

Lorsque l’instruction est incluse au niveau hiérarchique, les fichiers journaux traceoptions flag all[edit snmp] suivants sont créés:

  • Snmpd

  • mib2d

  • rmopd

FAQ sur SNMPv3

Cette section présente des questions et réponses fréquentes associées à SNMPv3.

Why is SNMPv3 important?

SNMP v3 offre une sécurité améliorée par rapport aux autres versions de SNMP. Elle fournit l’authentification et le chiffrement des données. Le renforcement de la sécurité est important pour la gestion des équipements sur les sites distants à partir des stations de gestion.

In my system, the MIB object snmpEngineBoots is not in sync between two Routing Engines in a dual Routing Engine device. Is this normal behavior?

C’est le comportement attendu. Chaque moteur de routage exécute son propre processus SNMP (snmpd), permettant à chaque moteur de routage de conserver ses propres bottés de moteur. Toutefois, si les deux moteurs de routage ont le même ID de moteur et le moteur de routage à valeur moindre est sélectionné comme moteur de routage principal pendant le processus de basculement, la valeur du moteur de routage principal est synchronisée avec la valeur de l’autre moteur de snmpEngineBootssnmpEngineBootssnmpEngineBoots routage.

Do I need the SNMP manager engine object identifier (OID) for informs?

Oui, le moteur OID du gestionnaire SNMP est requis pour l’authentification et les informations ne fonctionnent pas sans elle.

I see the configuration of informs under the [edit snmp v3] hierarchy. Does this mean I cannot use informs with SNMPv2c?

Les informations peuvent être utilisées avec SNMPv2c. L’exemple suivant illustre la configuration de base des informations de base de SNMPv3 sur un équipement (remarque: l’authentification et la confidentialité ne sont pas définies):

Vous pouvez convertir les informations de SNMPv3 en traps en établissant la valeur de l’énoncé au niveau de la hiérarchie sur l’exemple type[edit snmp v3 notify N1_all_tl1_informs]trap suivant:

FAQ sur l’interaction entre SNMP Juniper Networks périphériques mobiles

Cette section présente des questions et réponses fréquentes relatives à la façon dont SNMP interagit avec Juniper Networks périphériques.

How frequently should a device be polled? What is a good polling rate?

Il est difficile de fournir un chiffre absolu pour le taux de participation aux enquêtes SNMP par seconde, car ce taux dépend des deux facteurs suivants:

  • Nombre de liaisons variables dans une unité de données de protocole (PDU)

  • Le temps de réponse d’une interface du moteur de transfert de paquets

Dans un scénario normal où le moteur de transfert de paquets ne présente aucun délai et qu’une variable est présente par PDU (demande d’aide), le temps de réponse est de plus de 130 réponses par seconde. Cependant, avec plusieurs variables dans une demande PDU SNMP (30 à 40 pour les demandes GetBulk), le nombre de réponses par seconde est beaucoup moins important. Dans la moteur de transfert de paquets, la charge de travail peut varier pour chaque système, la fréquence des sondages d’un équipement est plus variable.

Les interrogations fréquentes d’un grand nombre de compteurs, en particulier les statistiques, peuvent avoir un impact sur l’équipement. Il est recommandé d’optimiser les gestionnaires SNMP suivants:

  • Utilisez la méthode d’interrogation row-by-row, et non la méthode colonne par colonne.

  • Réduisez le nombre de liaisons variables par PDU.

  • Augmentation des valeurs d’écart dans les intervalles d’interrogation et de découverte.

  • Réduisez la vitesse des paquets entrants lors du processus SNMP (snmpd).

Pour une meilleure réponse SNMP sur l’équipement, l’équipe Junos OS fait les choses suivantes:

  • Filtre les demandes SNMP en double.

  • N’exclut pas les interfaces en réponse lentes à partir des requêtes SNMP.

Une des façons de déterminer une limite de taux est de noter une augmentation du nombre Currently Active de la show snmp statistics extensive commande.

Voici un exemple de show snmp statistics extensive commande:

Does SNMP open dynamic UDP ports? Why?

Le processus SNMP ouvre deux ports supplémentaires (connecteurs): un pour IPv4 et un pour IPv6. Cela permet au processus SNMP d’envoyer des traps.

I am unable to perform a MIB walk on the ifIndex. Why is this?

Les caractères ou valeurs variables ayant un niveau d’accès ne peuvent pas être interrogés directement, car ils font partie d’autres liaisons variables dans le tableau de MIB not-accessible SNMP. L’ifIndex a un niveau d’accès de not-accessible . Par conséquent, elle ne peut pas être directement accessible, car elle fait partie des liaisons variables. Cependant, l’ifIndex peut être accessible indirectement par le biais des liaisons variables.

I see SNMP_IPC_READ_ERROR messages when the SNMP process restarts on my system and also during Routing Engine switchover. Is this acceptable?

Oui, il est acceptable de voir les messages lors du redémarrage du processus SNMP, du redémarrage du système ou SNMP_IPC_READ_ERROR d’un basculement moteur de routage réseau. Si tous les processus réussissent et que les opérations SNMP fonctionnent correctement, ces messages peuvent être ignorés.

What is the source IP address used in the response PDUs for SNMP requests? Can this be configured?

L’adresse IP source utilisée dans les PPO de réponse pour les requêtes SNMP est l’adresse IP de l’interface sortante pour atteindre la destination. L’adresse IP source ne peut pas être configurée pour les réponses. Elle ne peut être configurée que pour les traps.

Traps et informations SNMP FAQ

Cette section contient des questions et réponses fréquentes associées aux traps et informations SNMP.

Does the Junos OS impose any rate limiting on SNMP trap generation?

Le Junos OS met en œuvre un mécanisme de trap-file d’interrogation afin de limiter le nombre de traps générés et envoyés.

En cas d’échec d’une distribution de pièges, le piège est ajouté à la file d’attente, le compteur de la tentative de distribution et le compteur de la prochaine tentative de distribution pour la file d’attente sont réinitialisés. Les tentatives suivantes se produisent à intervalles progressifs de 1, 2, 4 et 8 minutes. Le délai maximum entre les tentatives est de 8 minutes et le nombre maximal de tentatives est de 10. Après 10 tentatives infructueuses, la file d’attente de destination et tous les pièges dans la file d’attente sont supprimés.

Junos OS possède également un mécanisme de seuil d’accélération permettant de contrôler le nombre de pièges envoyés (pièges de 500 par défaut) au cours d’un intervalle de limitation de l’étranglement particulier (5 secondes par défaut). Cela permet de garantir la cohérence du trafic piège, en particulier lorsqu’un grand nombre de pièges sont générés à cause de changements d’état d’interface.

L’intervalle de vitesse commence lorsque le premier piège arrive à l’accélérateur. Tous les pièges se rapportant à la valeur de seuil de vitesse sont traitées et les pièges qui dépassent la valeur de seuil sont mis en file d’attente. La taille maximale de toutes les files d’attente de trap (la file d’attente de l’accélérateur et la file d’attente de destination) est de 40 000 traps. La taille maximale d’une seule file d’attente est de 20 000 traps. Lorsqu’un piège est ajouté à la file d’attente de l’accélérateur ou si la file d’attente de l’étranglement a dépassé la taille maximale, le piège est transféré vers le haut de la file d’attente de destination. Les tentatives supplémentaires d’envoi du piège depuis la file d’attente de destination sont interrompues pendant une période de 30 secondes, après quoi la file d’attente de destination redémarre l’envoi des traps.

Remarque :

Pour le Juniper Networks EX Series Commutateur Ethernet, la taille maximale de toutes les files d’attente de trap (la file d’attente de l’accélérateur et la file d’attente de destination) est de 1 000 traps. La taille maximale pour n’importe quelle file d’attente sur le EX Series est de 500 traps.

I did not see a trap when I had a syslog entry with a critical severity. Is this normal? Can it be changed?

Chaque entrée syslog dont la gravité est critique n’est pas un piège. Toutefois, vous pouvez convertir n’importe quelle entrée syslog en un piège en utilisant event-options l’instruction.

L’exemple suivant indique comment configurer un message jnxSyslogTrap d’entrée syslog en cas rpd_ldp_nbrdown d’erreur.

Are SNMP traps compliant with the Alarm Reporting Function (X.733) on the Junos OS?

Non, les traps SNMP du Junos OS ne sont pas compatibles X.733.

Can I set up filters for traps or informs?

Les traps et informations peuvent être filtrés en fonction de la catégorie du piège et de l’identifiant d’objet. Vous pouvez spécifier des catégories de traps à recevoir par hôte en utilisant categories l’instruction au niveau de la [edit snmp trap-group trap-group] hiérarchie. Utilisez cette option lorsque vous souhaitez surveiller uniquement des modules spécifiques de la Junos OS.

L’exemple suivant illustre un exemple de configuration à recevoir uniquement linkvrrp-events , et servicesotn-alarms traps:

Le Junos OS dispose également d’une option de filtre plus avancée () pour le filtrage de traps spécifiques ou d’un groupe de traps basé sur notify-filter leurs identifiants d’objet.

La configuration SNMPv3 prend également en charge le filtrage des traps SNMPv1 et SNMPv2 et n’Juniper Networks pas de pièges de gestion de configuration spécifiques à l’entreprise, comme illustré dans l’exemple de configuration suivant:

Can I simulate traps on a device?

Oui, vous pouvez utiliser la commande pour simuler un piège vers le NMS qui reçoit normalement les request snmp spoof-trap trap name traps de votre équipement. Vous pouvez également ajouter des valeurs requises à l’aide des variable-bindings paramètres.

L’exemple suivant montre comment simuler un piège vers le NMS local à l’aide de liaisons variables:

How do I generate a warm start SNMPv1 trap?

Lorsque le processus SNMP est redémarré dans des conditions normales, un piège de démarrage chaud est généré si le temps de fonctionnement du système est supérieur à 5 minutes. Si le temps de démarrage du système est inférieur à 5 minutes, un piège est créé.

The NMS sees only the MIB OIDs and numbers, but not the names of the SNMP traps. Why?

Avant que le NMS puisse identifier les détails du piège SNMP, tels que le nom des traps, il doit d’abord compiler et comprendre les MIM, puis MIB OIDs.

In the Junos OS, how can I determine to which category a trap belongs?

Pour une liste des pièges courants et de leurs catégories, consultez les traps SNMP spécifiquesà l’entreprise pris en charge par Junos OS .

Can I configure a trap to include the source IP address?

Oui, vous pouvez configurer la , ou le nom de l’adresse IP source à source-address l’aide routing-instance de la logical-instancetrap-options commande:

Can I create a custom trap?

Oui, vous pouvez utiliser le jnxEventTrap script d’événement pour créer des traps personnalisés selon vos besoins.

Dans l’exemple suivant, un script opérationnel Junos OS opérations de sécurité est déclenché UI_COMMIT_NOT_CONFIRMED lorsqu’un événement est reçu. Le script Junos OS opérations est en correspondance avec le message complet de l’événement et génère un piège SNMP.

Exemple: Junos OS Op Script

Après avoir créé votre piège personnalisé, vous devez configurer une stratégie sur votre équipement pour lui indiquer les actions à prendre après qu’il a reçu ce piège.

Voici un exemple de stratégie configurée sous la [edit event-options] hiérarchie:

Can I disable link up and link down traps on interfaces?

Oui, il est possible de désactiver les pièges de liaison vers le haut et vers le bas dans la configuration de l’interface. Pour désactiver les pièges, utilisez l’instruction au niveau des hiérarchies pour les interfaces physiques no-traps[edit interfaces interface-name unit logical-unit-number] et [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] logiques.

I see the link up traps on logical interfaces, but I do not see the link down traps. Is this normal behavior?

Pour les types d’interfaces Ethernet et ATM, Junos OS n’envoie pas de pièges de liaison vers une interface logique si l’interface physique est en panne pour éviter les alarmes d’inondantes pour la même cause racine. Cependant, lorsque l’interface physique et les interfaces logiques reviennent, des traps sont envoyés indiquant la liaison vers le haut. Cela n’est pas nécessairement le cas des interfaces logiques.

Pour les types d’interfaces SONET avec encapsulation PPP, Junos OS envoie des pièges de liaison vers une interface logique en cas de panne de l’interface physique. Lorsque l’interface physique et les interfaces logiques reviennent, des pièges sont envoyés pour les interfaces physiques et logiques indiquant la liaison vers le haut.

Pour les types d’interfaces SONET avec encapsulation HDLC, Junos OS n’envoie pas de liens vers le bas pour une interface logique en cas de panne de l’interface physique. Lorsque l’interface physique et les interfaces logiques reviennent, des pièges sont envoyés pour les interfaces physiques et logiques indiquant la liaison vers le haut.

Pour les interfaces de channelize avec l’encapsulation PPP, Junos OS envoie des traps de liaison vers le bas pour une interface logique en cas de panne de l’interface physique. Lorsque l’interface physique et les interfaces logiques reviennent, des pièges sont envoyés pour les interfaces physiques et logiques indiquant la liaison vers le haut.

Pour les interfaces channelize avec l’encapsulation HDLC, Junos OS n’envoie pas de pièges de liaison vers le bas pour une interface logique en cas de panne de l’interface physique. Lorsque l’interface physique et les interfaces logiques reviennent, des pièges sont envoyés pour les interfaces physiques et logiques indiquant la liaison vers le haut.

FAQ Junos OS sur la moteur de routage double configuration réseau

Cette section présente des questions et réponses fréquentes relatives à la configuration de deux moteurs de routage.

La configuration SNMP doit être identique entre les moteurs de routage lors de la configuration pour une communication continue. Toutefois, nous recommandons d’avoir moteur de routage d’ID distincts configurés pour chaque moteur de routage, lors de l’utilisation de SNMPv3.

In my system, the MIB object snmpEngineBoots is not in sync between two Routing Engines in a dual Routing Engine device. Is this normal behavior?

Oui. C’est un comportement normal. Chaque moteur de routage son propre agent SNMP (snmpd), ce qui permet à chaque moteur de routage de conserver ses propres bottés de moteur.

Is there a way to identify that an address belongs to RE0, RE1, or the master Routing Engine management interface (fxp0) by looking at an SNMP walk?

non. Lorsque vous faites une promenade SNMP sur l’équipement, elle affiche uniquement l’adresse principale moteur de routage interface de gestion.

What is the best way to tell if the current IP address belongs to fxp0 or a Routing Engine, from a CLI session?

Les moteurs de routage sont interatrés avec fxp0 l’interface. Cela signifie que lorsque vous interrogez RE0, l’adresse ifTable ne signale que fxp0 l’adresse de l’interface RE0. De même, si vous interrogez RE1, l’adresse ifTable ne signale que fxp0 l’adresse de l’interface RE1.

When there is a failover, the master hostname is changed since the hostname belongs to the Routing Engine. Is this correct?

Oui. Vous pouvez configurer le même nom d’hôte ou différents noms d’hôte. L’un comme l’autre fonctionnent.

Si seule l’adresse IP principale est configurée (par exemple, 192.168.2.5) et que l’objet dispose de la même chaîne configurée sur les deux moteurs de routage, alors même après le basculement, l’objet renvoie la même sysDescr.0sysDescr.0 valeur. L’exemple suivant montre les résultats obtenus grâce à la snmpget commande:

FAQ sur la prise en charge SNMP des instances de routage

Cette section présente des questions et réponses fréquentes relatives à la façon dont SNMP prend en charge les instances de routage.

Can the SNMP manager access data for routing instances?

Oui, la Junos OS permet aux gestionnaires SNMP pour toutes les instances de routage de demander et de gérer les données SNMP liées aux instances de routage correspondantes et aux réseaux du système logique.

Deux comportements d’instance de routage différents peuvent se produire, selon l’origine des clients:

  • Les clients d’instances de routage autres que le système par défaut peuvent accéder MIB objets et n’effectuent des opérations SNMP que sur les réseaux du système logique auquel ils appartiennent.

  • Les clients de l’instance de routage par défaut peuvent accéder à des informations relatives à toutes les instances de routage et aux réseaux du système logique.

Les instances de routage sont identifiées soit par le contexte présent dans les requêtes SNMPv3, soit par le code de la chaîne de la communauté dans les requêtes SNMPv1 ou SNMPv2c.

Une fois encodé dans une chaîne de la communauté, le nom de l’instance de routage apparaît en premier et est séparé de la chaîne de la communauté réelle par le caractère @.

Pour éviter les conflits avec des chaînes communautaires valides qui contiennent le caractère @, la communauté n’est traitée que si le traitement des chaînes de la communauté classique échoue. Par exemple, si une instance de routage nommée est configurée, une demande de SNMP avec est traitée dans le RIRI@public contexte de RI l’instance de routage. Le contrôle des accès (notamment les vues, les restrictions d’adresses source et les privilèges d’accès) est appliqué en fonction de la chaîne de la communauté réelle (ensemble de données après le caractère @, dans ce public cas). Toutefois, si la chaîne de la communauté est configurée, le PDU est traitée conformément à cette communauté, et le nom de l’instance de routage intégré est RI@public ignoré.

Les systèmes logiques exécutent un sous-ensemble des actions d’un routeur physique et possèdent leurs propres tables de routage, interfaces, stratégies et instances de routage uniques. Lorsqu’une instance de routage est définie au sein d’un système logique, le nom du système logique doit être encodé en même temps que l’instance de routage à l’aide d’une barre de frappe (/) pour séparer les deux. Par exemple, si l’instance de routage est configurée dans le système logique, cette instance de routage doit être RILS encodée au sein d’une chaîne de communauté comme LS/RI@public . Lorsqu’une instance de routage est configurée en dehors d’un système logique (dans le système logique par défaut), aucun nom ou caractère du système / logique n’est nécessaire.

En outre, lorsqu’un système logique est créé, une instance de routage par défaut nommée est default toujours créée au sein du système logique. Ce nom doit être utilisé pour interroger les données de cette instance de routage, par LS/default@public exemple. Pour les requêtes SNMPv3, le nom doit être logical system/routing instance identifié directement dans le champ de contexte.

Can I access a list of all routing instances on a device?

Oui, vous pouvez accéder à une liste de toutes les instances de routage d’un équipement à l’aide de l’objet vacmContextName dans le SNMP-VIEW-BASED-ACM MIB. Dans SNMP, chaque instance de routage devient un contexte VACM . C’est pourquoi les instances de routage apparaissent dans l’objet vacmContextName.

Can I access a default routing instance from a client in another logical router or routing instance?

Non, l’agent SNMP n’a accès qu’aux données du routeur logique auquel il est connecté.

SNMP compteurs FAQ

Cette section contient des questions et réponses fréquentes associées aux compteurs SNMP.

Which MIB should I use for interface counters?

La gestion des interfaces sur SNMP est basée sur deux tableaux: et ifTable son extension, le ifXTable . Tous deux sont décrits dans le RFC 1213, base d’informations de gestion pour la gestion du réseau des internets basés sur TCP/IP: MIB-II et RFC 2233, the Interfaces Group MIB en utilisant SMIv2.

Les interfaces peuvent avoir plusieurs couches selon le support, et chaque sous-couche est représenté par une ligne distincte dans le tableau. La relation entre la couche supérieure et la couche inférieure est décrite dans le ifStackTable .

Les compteurs 32 bits définissent les ifTable octets entrants et sortants (ifInOctets/ifOutOctets), les paquets (ifInUcastPkts/ifOutUcastPkts, ifInNUcastPkts /ifOutNUcastPkts), les erreurs et les écarts.

Il fournit des compteurs 64 bits similaires, également appelés compteurs de capacité élevée (HC), pour les octets entrants et ifXTable sortants (ifHCInOctets/ifHCOutOctets) et les paquets entrants (ifHCInUcastPkts).

When should 64-bit counters be used?

Il est toujours bon d’utiliser des compteurs 64 bits, car ils contiennent des statistiques pour les composants à faible et haute capacité.

Are the SNMP counters ifInOctets and ifOutOctets the same as the command reference show interfaces statistics in and out counters?

Il s’agit là de la même chose, mais uniquement si le SNMP est activé lorsque le routeur démarre. Si vous activez une Juniper Networks puis activez SNMP, les compteurs SNMP commencent par 0. Les compteurs SNMP ne reçoivent pas automatiquement leurs statistiques à partir du show résultat de commande. De même, l’utilisation de la commande ne permet pas d’effacer les statistiques collectées par les compteurs SNMP, ce qui peut provoquer des écarts au niveau des données observés par clear statistics les deux processus.

Do the SNMP counters ifInOctets and ifOutOctets include the framing overhead for Point-to-Point Protocol (PPP) and High-Level Data Link Control (HDLC)?

Oui.

Gérer les pièges et les informations

Les sections suivantes contiennent quelques conseils sur la gestion des notifications SNMP:

Générer des pièges basés sur les événements SysLog

Les stratégies d’événements peuvent inclure une action qui élève des traps pour les événements basés sur les messages de journal système. Cette fonctionnalité permet de notification d’une application basée sur un piège SNMP lorsqu’un message de journal système important se produit. Vous pouvez convertir un message de journal système pour lequel il n’y a aucun piège correspondant dans un piège. Si vous utilisez des traps du système de gestion réseau plutôt que des messages de journal système pour surveiller votre réseau, vous pouvez utiliser cette fonctionnalité pour vous assurer d’être informé de tous les événements majeurs.

Pour configurer une stratégie qui élève un piège à la réception d’un événement, inclure les instructions suivantes au niveau [edit event-options policy policy-name] de la hiérarchie:

L’exemple suivant illustre la configuration de l’échantillon pour lever un piège pour ui_mgd_terminate l’événement:

Générer des pièges basés sur les événements SysLog

Traps de filtrage basés sur la catégorie trap

Les traps SNMP sont catégorisés dans de nombreuses catégories. Le Junos OS fournit une option de configuration, au niveau de la hiérarchie, qui vous permet de spécifier des catégories de traps que vous souhaitez recevoir sur categories[edit snmp trap-group trap-group] un hôte particulier. Vous pouvez utiliser cette option lorsque vous souhaitez surveiller uniquement des modules spécifiques de la Junos OS.

L’exemple suivant illustre un exemple de configuration à recevoir uniquement linkvrrp-events , et servicesotn-alarms traps:

Traps de filtrage basés sur l’identifiant de l’objet

La Junos OS également une option de filtre plus avancée qui vous permet de filtrer des traps spécifiques en fonction de leurs identifiants d’objet. Vous pouvez utiliser notify-filter l’option de filtrer un piège ou un groupe de pièges spécifiques.

L’exemple suivant illustre la configuration d’exemple à exclure des pièges de gestion de configuration propres à l’entreprise de Juniper Networks (remarque: la configuration SNMPv3 prend également en charge le filtrage des traps SNMPv1 et SNMPv2, comme illustré dans l’exemple suivant):