Comprendre l’implémentation SNMP dans Junos OS
SNMP sur Junos OS
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Consultez la section Comportement de la file d’attente d’interruption SNMP spécifique à la plate-forme pour obtenir des notes relatives à votre plate-forme.
Sous Junos OS, SNMP utilise à la fois des MIB standard (développées par l’IETF et documentées dans les RFC) et spécifiques à Juniper Networks pour l’entreprise.
Par défaut, SNMP n’est pas activé sur les équipements exécutant Junos OS.
Dans Junos OS, les processus qui gèrent les données de gestion SNMP sont les suivants :
-
Un agent SNMP maître réside sur l’équipement géré et est géré par le NMS ou l’hôte.
Le logiciel de l’agent SNMP de Junos OS est constitué d’un agent primaire SNMP (processus SNMP ou snmpd). Il réside sur l’appareil géré et est géré par le NMS ou l’hôte.
-
Divers sous-agents résidant 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-agents. Chaque sous-agent est responsable de la prise en charge d’un ensemble spécifique de MIB.
-
Processus Junos OS qui partagent des données avec les sous-agents lorsqu’ils sont interrogés pour des données SNMP (par exemple, les MIB liées à l’interface).
La chaîne de communauté est le premier niveau d’authentification de gestion implémenté par l’agent SNMP dans Junos OS.
Consultez les sections suivantes pour plus d’informations.
- Prise en charge de Junos OS pour les versions SNMP
- Niveaux de sévérité de journalisation système pour les interruptions SNMP
- Flux de communication SNMP
- File d’attente pour les pièges
Prise en charge de Junos OS pour les versions SNMP
Junos OS prend en charge les versions SNMP suivantes. Pour plus d’informations, voir Tableau 1.
| SNMP Versions | Descriptif |
|---|---|
| SNMPv1 | Implémentation initiale de SNMP qui définit l’architecture et le cadre de SNMP. |
| SNMPv2c | Le protocole révisé, avec des améliorations au rendement et aux communications entre gestionnaires. Plus précisément, SNMPv2c implémente des chaînes de communauté, qui servent de mots de passe pour déterminer qui, quoi et comment les clients SNMP peuvent accéder aux données de l’agent SNMP. La chaîne de communauté est contenue dans SNMP |
| SNMPv3 | SNMPv3 : le protocole le plus récent est axé sur la sécurité. 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). SNMPv3 USM assure l’intégrité des données, l’authentification de l’origine des données, la protection contre la relecture des messages et la protection contre la divulgation de la charge utile du message. Le VACM SNMPv3 fournit un contrôle d’accès pour déterminer si un type d’accès spécifique (lecture ou écriture) aux informations de gestion est autorisé. |
De plus, le logiciel de l’agent SNMP de Junos OS accepte les adresses IPv4 et IPv6 pour le transport sur IPv4 et IPv6. Pour IPv6, Junos OS prend en charge les fonctionnalités suivantes :
-
Données SNMP sur les réseaux IPv6
-
Données MIB spécifiques à IPv6
-
Agents SNMP pour IPv6
Niveaux de sévérité de journalisation système pour les interruptions SNMP
Pour certaines interruptions, lorsqu’une condition d’interruption se produit, que l’agent SNMP envoie ou non une interruption à un NMS, l’interruption est consignée si la journalisation système est configurée pour consigner un événement avec ce niveau de gravité de journalisation système.
Pour plus d’informations sur les niveaux de sévérité de journalisation du système pour les interruptions standard et spécifiques à l’entreprise, consultez Interruptions SNMP prises en charge par Junos OS.
Flux de communication SNMP
Lorsqu’un NMS interroge l’agent primaire pour obtenir des données, celui-ci 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-agents. Toutefois, si les données demandées n’appartiennent pas aux catégories gérées par l’agent principal ou les sous-agents, le sous-agent interroge le noyau Junos OS ou le processus qui gère ces données. À la réception des données requises, le sous-agent transmet la réponse à l’agent primaire, qui la transmet à son tour au NMS.
La figure 1 montre le flux de communication entre le NMS, l’agent primaire SNMP (snmpd), les sous-agents SNMP, le noyau Junos OS et le moteur de transfert de paquets.
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 : intercepte et informe. Les interruptions sont des notifications non confirmées, tandis que les informations sont des notifications confirmées. Les Inform ne sont pris en charge que sur les équipements qui prennent en charge la configuration SNMP version 3 (SNMPv3).
File d’attente pour les pièges
Junos OS prend en charge les files d’attente d’interruption pour s’assurer que les interruptions ne sont pas perdues en raison de l’indisponibilité temporaire des routes. Deux types de files d’attente, les files d’attente de destination et la file d’attente d’étranglement, sont formés pour assurer la livraison des interruptions et contrôler le trafic des interruptions.
Vous ne pouvez pas configurer la mise en file d’attente des interruptions dans Junos OS. Vous ne pouvez pas afficher d’informations sur les files d’attente d’interruption à l’exception de ce qui est fourni dans les journaux système.
Junos OS crée une file d’attente de destination lorsqu’une interruption vers une destination particulière est renvoyée parce que l’hôte n’est pas joignable, et ajoute les interruptions suivantes à la même destination dans la file d’attente. Junos OS vérifie la disponibilité des routes toutes les 30 secondes et envoie les interruptions de la file d’attente de destination de manière circulaire.
Si la livraison de l’interruption échoue, l’interruption est rajoutée à la file d’attente et le compteur de tentatives de remise et le minuteur de la prochaine tentative de livraison de la file d’attente sont réinitialisés. Les tentatives suivantes ont lieu à des 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 maximum de tentatives est de 10. Après 10 tentatives infructueuses, la file d’attente de destination et toutes les interruptions de la file d’attente sont supprimées.
Junos OS dispose également d’un mécanisme de limitation pour contrôler le nombre d’interruptions (seuil d’accélération ; valeur par défaut de 500 interruptions) envoyées au cours d’une période donnée (intervalle d’accélération ; valeur par défaut de 5 secondes) et pour assurer la cohérence du trafic d’interruptions, en particulier lorsqu’un grand nombre d’interruptions sont générées en raison de changements d’état d’interface. La période d’intervalle d’accélération commence lorsque le premier piège arrive à l’accélérateur. Toutes les interruptions comprises dans le seuil d’interruption sont traitées et celles situées au-delà de la limite de seuil sont mises en file d’attente.
La taille maximale de toutes les files d’attente d’interruption (la file d’attente d’étranglement et la file d’attente de destination) est de 40 000 interruptions. La taille maximale d’une file d’attente est de 20 000 interruptions. Lorsqu’une interruption est ajoutée à la file d’attente d’accélération, ou si la file d’attente d’accélération a dépassé la taille maximale, l’interruption est rajoutée au-dessus de la file d’attente de destination et toutes les tentatives ultérieures de la file d’attente de destination sont arrêtées pendant une période de 30 secondes, après quoi la file d’attente de destination recommence à envoyer les interruptions.
Chargement de fichiers MIB dans un système de gestion de réseau
Pour que votre système de gestion de réseau (NMS) identifie et comprenne les objets MIB utilisés par Junos OS, vous devez d’abord charger les fichiers MIB dans votre NMS à l’aide d’un compilateur MIB. Un compilateur MIB est un utilitaire 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 à partir de l’index Junos OS Enterprise MIBs dans SNMP MIB Explorer. Le pack MIB Junos est disponible en packs .zip et .tar . 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 StandardMibs contient les MIB et RFC standard prises en charge sur les équipements exécutant Junos OS, tandis que le dossier JuniperMibs contient les MIB d’entreprise spécifiques à Juniper Networks.
Pour charger les fichiers MIB nécessaires à la gestion et à la surveillance des équipements exécutant Junos OS :
Lors du chargement d’un fichier MIB, si le compilateur renvoie un message d’erreur indiquant que l’un des objets n’est pas défini, ouvrez le fichier MIB à l’aide d’un éditeur de texte et assurez-vous que tous les fichiers MIB répertoriés dans la section IMPORT sont chargés sur le compilateur. Si l’un des fichiers MIB répertoriés dans la section IMPORT n’est pas chargé sur le compilateur, chargez ce fichier MIB, puis essayez de charger le fichier MIB qui n’a pas pu se charger.
Par exemple, le MIB PING spécifique à l’entreprise, mib-jnx-ping.txt, dépend de RFC 2925, DiSMAN-PING-MIB mib-rfc2925a.txt. Si vous essayez de charger mib-jnx-ping.txt avant de charger mib-rfc2925a.txt, le compilateur renvoie un message d’erreur indiquant que certains objets de mib-jnx-ping.txt ne sont pas définis. Chargez mib-rfc2925a.txt, puis essayez de charger mib-jnx-ping.txt. Le PING spécifique à l’entreprise MIB, mib-jnx-ping.txt, se charge ensuite sans problème.
Comprendre l’interface de gestion locale intégrée
L’interface de gestion locale intégrée (ILMI) fournit un mécanisme permettant aux périphériques connectés en mode de transfert asynchrone (ATM), tels que les hôtes, les routeurs et les commutateurs ATM, de transférer les informations de gestion. L’ILMI assure un échange bidirectionnel d’informations de gestion entre deux interfaces ATM sur une connexion physique. Les informations ILMI sont échangées via une encapsulation directe de SNMP version 1 (RFC 1157, A Simple Network Management Protocol) sur ATM Adaptation Layer 5 (AAL5) à l’aide d’une valeur d’identificateur de chemin virtuel/identifiant de canal virtuel (VPI/VCI) (VPI=0, VCI=16).
Junos OS ne prend en charge que deux variables MIB ILMI :
-
atmfMYIPNmAddress -
atmfPortMyIfname
Pour les interfaces de file d’attente intelligentes (IQ) ATM1 et ATM2, vous pouvez configurer ILMI pour qu’il communique directement avec un commutateur ATM connecté afin d’activer l’interrogation de l’adresse IP et du numéro de port du commutateur.
Pour plus d’informations sur la MIB ILMI, voir atmfMYIPNmAddress ou atmfPortMyIfname dans l’explorateur de MIB SNMP.
Voir aussi
Comportement de la file d’attente d’interruption SNMP spécifique à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.
| Plate-forme | Différence |
|---|---|
| EX Series |
|