Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Configuration de base de SNMP

Déclarations de configuration au niveau de la hiérarchie [edit snmp]

Ce sujet affiche toutes les déclarations de configuration possibles au niveau de la hiérarchie et leur [edit snmp] niveau dans la hiérarchie de configuration. Lorsque vous configurez une Junos OS, le niveau de hiérarchie actuel est affiché sur la bannière de la ligne qui précède user@host# l’invite.

Configuration de SNMP

SNMP est implémenté dans le Junos OS qui s’exécute sur les QFX Series et OCX Series. Par défaut, le SNMP n’est pas activé. Pour activer SNMP, vous devez inclure les instructions de configuration SNMP au niveau [edit] de la hiérarchie.

Pour configurer les exigences minimales pour SNMP, inclure les instructions suivantes au niveau hiérarchique [edit] de la configuration:

Pour configurer les fonctionnalités SNMP complètes, inclure les instructions suivantes au niveau hiérarchique [edit] de la configuration:

Optimiser la configuration du système de gestion réseau pour obtenir les meilleurs résultats

Vous pouvez modifier la configuration de votre système de gestion réseau pour optimiser le temps de réponse pour les requêtes SNMP. Les sections suivantes contiennent quelques conseils pour configurer le système de gestion du réseau:

Modification de la méthode d’interrogation de colonne par colonne à row-by-row

Vous pouvez configurer le système de gestion réseau pour utiliser la méthode row-by-row pour la méthode d’interrogation des données SNMP. Il a été prouvé que les méthodes de sondage row-by-row et plusieurs méthodes d’interrogation row-by-multiple-row sont plus efficaces que les méthodes de sondage colonne par colonne. En configurant le système de gestion réseau pour qu’il utilise une méthode d’interrogation des données, vous pouvez vous assurer que les données pour une seule interface sont sondées en requête plutôt qu’en demande unique pour plusieurs interfaces, comme c’est le cas pour l’interrogation de colonnes par colonne. L’interrogation par ligne réduit également le risque d’délais d’interrogation des requêtes.

Réduction du nombre de liaisons variables par PDU

En réduisant le nombre de liaisons variables par unité de données de protocole (PDU), vous pouvez améliorer le temps de réponse aux requêtes SNMP. Une demande que les sondages pour obtenir des données liées à plusieurs objets, associés à différentes entrées d’index, se traduisent en plusieurs requêtes à la fin de l’équipement, car le sous-équipement peut devoir sonder différents modules pour obtenir des données liées à différentes entrées d’index. La méthode recommandée consiste à s’assurer qu’une demande ne possède que des objets liés à une entrée d’index plutôt que plusieurs objets liés à différentes entrées d’index.

Remarque :

Si les réponses d’un équipement sont lentes, évitez d’utiliser l’option pour l’équipement, car une demande peut contenir des objets qui sont liés à diverses entrées d’index et peut encore augmenter le temps de GetBulkGetBulk réponse.

Augmentation des valeurs de délai d’interrogation et de découverte

En augmentant les valeurs d’délais d’accélération pour les intervalles d’interrogation et de découverte, vous pouvez augmenter le temps de file d’file d’file à la fin de l’équipement et réduire le nombre de baisses de vitesse qui se produisent à cause de l’accélération du délai d’accélération.

Réduction du taux de paquets entrants au niveau du snmpd

En réduisant la fréquence d’envoi des requêtes SNMP à un équipement, vous pouvez réduire le risque d’empilement de requêtes SNMP sur un équipement particulier. Outre la réduction de la fréquence d’envoi des requêtes SNMP vers un équipement, vous pouvez également augmenter l’intervalle d’interrogation, contrôler l’utilisation des requêtes et réduire le nombre de bureaux de vote par GetNext équipement.

Configuration des options sur les équipements gérés pour un meilleur temps de réponse SNMP

Les sections suivantes contiennent des informations sur les options de configuration sur les équipements gérés qui peuvent améliorer les performances SNMP:

Filtrage des demandes SNMP en double

Si un poste de gestion de réseau retransmet trop souvent une demande de SNMP ou de requête SNMP vers un équipement, cette demande peut gêner le traitement des requêtes précédentes et ralentir le temps de réponse de GetGetNextGetBulk l’agent. Le filtrage de ces requêtes en double améliore le temps de réponse de l’agent SNMP. La Junos OS vous permet de filtrer les requêtes dupliquées GetGetNext et les requêtes GetBulk SNMP. Le Junos OS utilise les informations suivantes pour déterminer si une demande de SNMP est dupliquée:

  • Adresse IP source de la demande SNMP

  • Port UDP source de la demande SNMP

  • Demander l’ID de la demande de SNMP

Remarque :

Par défaut, le filtrage des requêtes SNMP dupliquées est désactivé sur les équipements exécutant le Junos OS.

Pour activer le filtrage des requêtes SNMP dupliquées sur les équipements exécutant le Junos OS, inclure l’énoncé au niveau filter-duplicates[edit snmp] de la hiérarchie:

Interfaces moins lentes à répondre aux requêtes SNMP

Une interface lente pour répondre aux demandes de statistiques d’interface SNMP peut reporter les réponses du noyau aux requêtes SNMP. Vous pouvez consulter le fichier journal mib2d pour savoir combien de temps le noyau prend pour répondre aux différentes demandes SNMP. Pour plus d’informations sur la révision du fichier journal pour obtenir des données de réponse au noyau, consultez « Checking Kernel and moteur de transfert de paquets Response » (Vérification du noyau et de la réponse moteur de transfert de paquets) dans la suite Monitoring SNMP Activity and Tracking Problems That Affect SNMP Performance on a Device Running Junos OS. Si vous remarquez qu’une interface ne répond pas rapidement et que le noyau ralentit la réponse aux requêtes SNMP, exclure cette interface depuis les requêtes SNMP vers l’équipement. Vous pouvez exclure une interface de la requête SNMP en configurant l’instruction ou en modifiant les filter-interface paramètres d’affichage SNMP.

L’exemple suivant illustre un exemple de configuration pour l’exclusion des interfaces du SNMP GetGetNext , et des Set opérations:

L’exemple suivant montre la configuration de la vue SNMP à l’exception de l’interface avec un index d’interface (ifIndex) de 312 sur une demande d’informations liée aux objets ifTable et ifXtable:

Vous pouvez également utiliser l’interface qui ne répond pas correctement.

Meilleures pratiques pour la configuration de SNMP

Les sections suivantes contiennent des informations sur la configuration SNMP de base et quelques exemples de configuration des opérations SNMP de base sur les équipements exécutant des Junos OS:

Configuration des paramètres de base pour SNMPv1 et SNMPv2

Par défaut, le SNMP n’est pas activé sur les équipements exécutant Junos OS. Pour activer le système SNMP sur les Junos OS, inclure community public l’instruction au niveau [edit  snmp] de la hiérarchie.

Activer les opérations Get and GetNext SNMPv1 et SNMPv2

Une communauté définie comme étant une communauté qui accorde l’accès à MIB données de tous les clients.

Pour activer les opérations SNMPv1 et SNMPv2 sur l’équipement, vous devez inclure les instructions suivantes au niveau de Set[edit snmp] la hiérarchie:

Activer les opérations définies par SNMPv1 et SNMPv2

L’exemple suivant illustre la configuration de base minimale des traps SNMPv1 et SNMPv2 sur un équipement:

Configuration des traps SNMPv1 et SNMPv2

Configuration des paramètres de base pour SNMPv3

L’exemple suivant montre la configuration SNMPv3 minimale pour l’activation , et les opérations sur un équipement (remarque: cette configuration dispose d’un ensemble d’authentification et de confidentialité GetGetNext permettant Setmd5none de):

Activer les opérations Get, GetNext et Set SNMPv3

L’exemple suivant illustre la configuration de base des informations de base de SNMPv3 sur un équipement (cette configuration dispose de l’authentification et de la confidentialité none suivantes):

Configuration des informations sur SNMPv3

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:

Conversion d’informations en traps

Configuration du nom, de l’emplacement, de la description et des coordonnées du système

Junos OS vous permet d’inclure le nom et la position du système, les informations de contact administratives et une brève description du système dans la configuration SNMP.

Remarque :

Gardez toujours le nom, l’emplacement, le contact et les informations de description configurés et mis à jour pour tous vos équipements gérés par SNMP.

L’exemple suivant illustre une configuration typique.

Conseil :

Utilisez des guillemets pour joindre les informations de nom, de contact, de localisation et de description du système contenant des espaces.

Configuration de SNMP sur un équipement s’exécutant Junos OS

Par défaut, le SNMP est désactivé sur les équipements qui s’exécutent Junos OS. Pour activer la fonction SNMP sur un routeur ou un commutateur, vous devez inclure les instructions de configuration SNMP au niveau [edit snmp] de la hiérarchie.

Pour configurer les exigences minimales pour SNMP, inclure les instructions suivantes au niveau hiérarchique [edit snmp] de la configuration:

La communauté telle qu’elle accorde un accès en lecture à MIB public données de tous les clients.

Pour configurer les fonctionnalités SNMP complètes, inclure les instructions suivantes au niveau [edit snmp] de la hiérarchie:

Configuration du contact système sur un équipement s’exécutant Junos OS

Vous pouvez spécifier un contact administratif pour chaque système géré par SNMP. Ce nom est placé dans l MIB II sysContact. Pour configurer un nom de contact, inclure contact l’instruction au niveau de la [edit snmp] hiérarchie:

Si le nom contient des espaces, joint dans des guillemets ( » « ).

Pour définir un nom de contact système contenant des espaces:

Configuration de l’emplacement système d’un équipement s’exécutant Junos OS

Vous pouvez spécifier l’emplacement de chaque système géré par SNMP. Cette chaîne est placée dans l’MIB SysLocation II. Pour configurer un emplacement du système, inclure location l’instruction au niveau de la [edit snmp] hiérarchie:

Si l’espace est contenu, enfermable dans des guillemets ( » « ).

Pour spécifier l’emplacement du système:

Configuration de la description du système sur un équipement s’exécutant Junos OS

Vous pouvez spécifier une description de chaque système géré par SNMP. Cette chaîne est placée dans l’objet MIB II de sysDescription. Pour configurer une description, inclure description l’instruction au niveau [edit snmp] de la hiérarchie:

Si la description contient des espaces, enfermables dans des guillemets ( » « ).

Pour spécifier la description du système:

Configuration des détails du SNMP

Vous pouvez utiliser SNMP pour stocker les détails administratifs de base, tels qu’un nom de contact et l’emplacement de l’équipement. Votre système de gestion peut ensuite récupérer ces informations à distance, lorsque vous dépanner un problème ou effectuer un audit. Dans la terminologie SNMP, il s’agit des objets sysContact, sysDescription et sysLocation du groupe système de MIB-2 (définis dans le RFC 1213, base d’informations de gestion for Network Management of TCP/IP-based Internets: MIB-II ). Vous pouvez définir les valeurs initiales directement dans la configuration Junos OS pour chaque système géré par SNMP.

Pour définir les coordonnées du système:

  1. Définissez les détails de contact du système en incluant l’énoncé au niveau de la hiérarchie ou dans un groupe de contact[edit snmp] configuration approprié, comme indiqué ici.

    Ce contact administratif est placé dans l’MIB SysContact II.

    Si le nom contient des espaces, joint dans des guillemets ( » « ).

    Quelques chiffres clés :

  2. Configurez une description du système.

    Cette chaîne est placée dans l’objet MIB II de sysDescription. Si la description contient des espaces, enfermables dans des guillemets ( » « ).

    Quelques chiffres clés :

  3. Configurez un emplacement du système.

    Cette chaîne est placée dans l’MIB SysLocation II. Si l’espace est contenu, enfermable dans des guillemets ( » « ).

    Pour spécifier l’emplacement du système:

    Quelques chiffres clés :

  4. Au niveau supérieur de la configuration, appliquez le groupe de configuration.

    Si vous utilisez un groupe de configurations, vous devez l’appliquer pour qu’il prenne effet.

  5. Valider la configuration.
  6. Pour vérifier la configuration, saisissez la show snmp mib walk system commande operational-mode.

    La commande effectue une MIB à la table système show snmp mib walk system (de MIB-2 telle que définie dans le RFC 1213). L’agent SNMP du Junos OS en imprimant chaque ligne de la table et sa valeur associée. Vous pouvez utiliser la même commande pour effectuer une MIB à travers n’importe quelle partie de l MIB e tree pris en charge par l’agent.

Configurer un nouveau nom de système

Junos OS vous permet de remplacer le nom du système en incluant l’instruction au niveau name[edit snmp] de la hiérarchie:

Si le nom contient des espaces, joint dans des guillemets ( » « ).

Pour spécifier le remplacement du nom du système:

Configuration du délai de validation

Lorsqu’un routeur ou un commutateur reçoit pour la première fois une demande de nonvolaune SNMP, une session de protocole XML Junos OS s’ouvre et empêche d’autres utilisateurs ou applications de modifier la configuration du candidat (équivalente à la commande Set interface de ligne de commande configure exclusive [CLI]. Si le routeur ne reçoit pas de nouvelles requêtes SNMP dans les 5 secondes (valeur par défaut), la configuration du candidat est engagée et la session de protocole XML de Junos OS se referme (la verrou de la configuration est Set publiée). Si le routeur reçoit de nouvelles requêtes SNMP alors que la configuration du candidat est engagée, la demande SNMP est rejetée et une erreur SetSet est générée. Si le routeur reçoit de nouvelles requêtes SNMP avant que cinq secondes ne s’écoulées, le délai de validation (la durée entre la dernière demande de SNMP et la validation demandée) est réinitialisé à Set 5 secondes.

Par défaut, le minuteur est placé sous 5 secondes. Pour configurer le timer pour la réponse SNMP et le début de la validation, inclure l’instruction au niveau Setcommit-delay de la [edit snmp nonvolatile] hiérarchie:

seconds est la durée entre la réception de la demande de SNMP et la validation de la configuration du candidat. Pour plus d’informations sur la commande et le verrouillage de la configure exclusive configuration, consultez le Junos OS CLI User Guide.

Filtrage des demandes SNMP dupliquées

Par défaut, le filtrage dupliqué et les requêtes SNMP sont désactivées sur les équipements exécutant getgetNextgetBulk Junos OS. Si un poste de gestion de réseau retransmet une demande de SNMP trop souvent au routeur, cette demande peut gêner le traitement des requêtes précédentes et ralentir le temps de réponse de GetGetNextGetBulk l’agent. Le filtrage de ces requêtes en double améliore le temps de réponse de l’agent SNMP. Junos OS utilise les informations suivantes pour déterminer si une demande de SNMP est dupliquée:

  • Adresse IP source de la demande SNMP

  • Port UDP source de la demande SNMP

  • Demander l’ID de la demande de SNMP

Pour filtrer les requêtes SNMP dupliquées, inclure l’énoncé au filter-duplicates niveau [edit snmp] de la hiérarchie:

Configuration des communautés SNMP

La configuration de l’agent SNMP dans Junos OS est une tâche simple qui partage de nombreux paramètres connus communs aux autres équipements gérés de votre réseau. Par exemple, vous devez configurer une Junos OS chaîne de communauté SNMP et une destination pour les traps. Les chaînes de communautés sont des noms administratifs qui groupent les ensembles d’équipements et les agents qui les exécutent ensemble dans des domaines de gestion courants. Si un responsable et un agent partagent la même communauté, ils peuvent communiquer entre eux. Une communauté SNMP définit le niveau d’autorisation accordé à ses membres, comme les objets MIB disponibles, les opérations (lecture seule ou lecture-écriture) valides pour ces objets et les clients SNMP autorisés, en fonction de leurs adresses IP source.

La chaîne de la communauté SNMP définit la relation entre un système de serveur SNMP et les systèmes clients. Cette chaîne agit comme un mot de passe pour contrôler l’accès des clients au serveur.

Pour créer une communauté SNMP en lecture seule:

  1. Entrez dans la communauté SNMP utilisée dans votre réseau.

    Si le nom de la communauté contient des espaces, joints aux guillemets ( » « ).

    Les noms de communauté doivent être uniques.

    Remarque :

    Vous ne pouvez pas configurer le même nom de communauté au niveau [edit snmp community] des niveaux [edit snmp v3 snmp-community community-index] hiérarchiques.

    Cet exemple utilise le nom standard pour créer une communauté qui offre un accès public en lecture seule limitée.

  2. Définir le niveau d’autorisation de la communauté.

    Le niveau d’autorisation par défaut d’une communauté est read-only .

    Pour autoriser Set les demandes au sein d’une communauté, vous devez définir cette communauté comme authorization read-write . Pour les requêtes, vous devez également inclure les objets de MIB qui sont accessibles avec des privilèges de lecture et d’écriture Set à l’aide de la view déclaration. La vue par défaut inclut tous les MIB d’accès accessibles avec des droits d’accès en lecture seule. Aucun objet MIB n’est accessible avec des droits de lecture.s. Pour plus d’informations sur view l’énoncé, consultez configuring MIB Views.

    Cet exemple limite l’accès en lecture seule à la communauté publique. Tout client SNMP (par exemple, un système de gestion SNMP) appartenant à la communauté publique peut lire MIB variables mais ne peut pas les définir.

  3. Définissez une liste de clients de la communauté autorisés à communiquer avec l’agent SNMP dans le Junos OS.

    La déclaration répertorie les adresses IP des clients (membres de la communauté) autorisés clients à utiliser cette communauté. Énumérer les clients par adresse IP et préfixe. En général, la liste inclut le système de gestion du réseau SNMP dans votre réseau ou l’adresse de votre réseau de gestion. Si aucune clients déclaration n’est présente, tous les clients sont autorisés. Pour address , vous devez spécifier une adresse IPv4 ou IPv6, et non un nom d’hôte.

    La déclaration suivante définit les hôtes du réseau 192.168.1.0/24 comme étant autorisés au sein de la communauté publique.

  4. Définissez les clients non autorisés au sein de la communauté en spécifiant leur adresse IP, suivi de la restrict déclaration.

    La déclaration suivante définit tous les autres hôtes comme étant restreints de la communauté publique.

  5. Au niveau supérieur de la configuration, appliquez le groupe de configuration.

    Si vous utilisez un groupe de configurations, vous devez l’appliquer pour qu’il prenne effet.

  6. Valider la configuration.

Pour créer une communauté SNMP en lecture:

  1. Entrez dans la communauté SNMP utilisée dans votre réseau.

    Cet exemple, chaîne de communauté standard permettant d’identifier la communauté qui a obtenu un accès en lecture-écriture à l’agent SNMP s’exécutant private sur l’équipement.

  2. Définir le niveau d’autorisation de la communauté.

    Cet exemple limite l’accès en lecture seule à la communauté publique. Tout client SNMP (par exemple, un système de gestion SNMP) appartenant à la communauté publique peut lire MIB variables mais ne peut pas les définir.

  3. Définissez une liste de clients de la communauté autorisés à apporter des modifications à l’agent SNMP dans Junos OS.

    Énumérer les clients par adresse IP et préfixe.

    Quelques chiffres clés :

  4. Définissez les clients non autorisés au sein de la communauté en spécifiant leur adresse IP, suivi de la restrict déclaration.

    La déclaration suivante définit tous les autres hôtes comme étant restreints de la communauté publique.

  5. Au niveau supérieur de la configuration, appliquez le groupe de configuration.

    Si vous utilisez un groupe de configurations, vous devez l’appliquer pour qu’il prenne effet.

  6. Valider la configuration.

Configuration de la chaîne de la communauté SNMP

La chaîne de la communauté SNMP définit la relation entre un système de serveur SNMP et les systèmes clients. Cette chaîne agit comme un mot de passe pour contrôler l’accès des clients au serveur. Pour configurer une chaîne de communauté dans une configuration Junos OS, inclure community l’instruction au niveau [edit snmp] de la hiérarchie:

Si le nom de la communauté contient des espaces, joints aux guillemets ( » « ).

Le niveau d’autorisation par défaut d’une communauté est read-only . Pour autoriser Set les demandes au sein d’une communauté, vous devez définir cette communauté comme authorization read-write . Pour les requêtes, vous devez également inclure les objets de MIB qui sont accessibles avec des privilèges de lecture et d’écriture Set à l’aide de la view déclaration. La vue par défaut inclut tous les MIB de données pris en charge qui sont accessibles avec des droits d’accès en lecture seule ; aucun MIB n’est accessible avec des droits de lecture. Pour plus d’informations sur view l’énoncé, consultez configuring MIB Views.

La déclaration répertorie les adresses IP des clients (membres de la communauté) autorisés clients à utiliser cette communauté. Si aucune clients déclaration n’est présente, tous les clients sont autorisés. Pour address , vous devez spécifier une adresse IPv4, et non un nom d’hôte. Inclure la possibilité de refuser l’accès à tous les clients SNMP pour lesquels l’accès default restrict n’est pas explicitement accordé. Il est recommandé de toujours inclure la possibilité de limiter l’accès default restrict client SNMP au commutateur local.

Remarque :

Les noms de communauté doivent être uniques au sein de chaque système SNMP.

Exemples: Configuration de la chaîne de la communauté SNMP

Grant est un accès en lecture seule pour tous les clients. Avec la configuration suivante, le système répond au SNMP et aux requêtes contenant la chaîne GetGetNext de la GetBulkpublic communauté:

Accorde à tous les clients un accès en lecture-écriture au ping MIB et jnxPingMIB . Avec la configuration suivante, le système répond au SNMP , ainsi qu’aux requêtes contenant la chaîne de la communauté et spécifiant un OID contenu dans la MIB ou la GetGetNextGetBulkSetprivatejnxPingMIB hiérarchie:

La configuration suivante autorise l’accès en lecture seule aux clients ayant des adresses IP dans la plage, et refuse l’accès aux systèmes de 1.2.3.4/24 la fe80::1:2:3:4/64 gamme:

Ajout d’un groupe de clients à une communauté SNMP

Junos OS vous permet d’ajouter un ou plusieurs groupes de clients à une communauté SNMP. Vous pouvez inclure l’instruction au niveau de la hiérarchie pour ajouter tous les membres de la liste de clients ou la liste de préfixe à une client-list-name name[edit snmp community community-name] communauté SNMP.

Pour définir une liste de clients, inclure l’instruction suivie par les adresses IP des clients au niveau client-list[edit snmp] hiérarchique:

Vous pouvez configurer une liste de préfixes au niveau [edit policy options] de la hiérarchie. La prise en charge des listes de préfixes dans la configuration de la communauté SNMP vous permet d’utiliser une seule liste pour configurer les stratégies SNMP et de routage. Pour plus d’informations sur cet énoncé, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des prefix-listpoliceurs du trafic.

Pour ajouter une liste de clients ou une liste de préfixes à une communauté SNMP, inclure l’énoncé au niveau client-list-name[edit snmp community community-name] de la hiérarchie:

Remarque :

La liste des clients et la liste de préfixes ne doivent pas avoir le même nom.

L’exemple suivant indique comment définir une liste de clients:

L’exemple suivant indique comment ajouter une liste de clients à une communauté SNMP:

L’exemple suivant illustre comment ajouter une liste de préfixes à une communauté SNMP:

Configuration d’un agent SNMP proxy

À partir de la version 12.3, Junos OS vous permet d’attribuer un des équipements du réseau comme agent SNMP proxy, via lequel le système de gestion du réseau (NMS) peut interroger d’autres équipements du réseau. Lorsque vous configurez un proxy, vous pouvez spécifier le nom des équipements à gérer via l’agent SNMP proxy.

Lorsque le NMS interroge l’agent SNMP proxy, le NMS spécifie le nom de la communauté (pour SNMPv1 et SNMPv2) ou le nom du contexte et de la sécurité (pour SNMPv3) associé à l’équipement à partir duquel il nécessite les informations.

Remarque :

Si vous avez configuré des méthodes d’authentification et des mots de passe pour SNMPv3, ces paramètres sont également spécifiés dans la requête d’informations SNMPv3.

Pour configurer un agent SNMP proxy et spécifier les équipements à gérer par l’agent SNMP proxy, vous pouvez inclure les instructions de configuration suivantes au niveau edit snmp hiérarchique [] :

  • Cette proxy instruction vous permet de spécifier un nom unique pour la configuration du proxy.

  • Le version-v1 , et les version-v2cversion-v3 instructions vous permettent de spécifier la version SNMP.

  • L’énoncé est une instruction facultative au niveau de [ ] hiérarchie qui, si elle est incluse dans la configuration, vous oblige à configurer manuellement les instructions aux niveaux hiérarchiques [ ] et no-default-comm-to-v3-configedit snmp proxy proxy-name <version-v1 | version-v2c> [ ] edit snmp v3 snmp-community community-nameedit snmp v3 vacm ;

    Si l’énoncé n’est pas inclus au niveau de [ ] hiérarchie, les configurations de niveau hiérarchique [ et [ ] sont automatiquement no-default-comm-to-v3-configedit snmp proxy proxy-name <version-v1 | version-v2c>edit snmp v3 snmp-community community-nameedit snmp v3 vacm initialisées.

  • Les déclarations et les déclarations sont des instructions facultatives qui vous permettent de spécifier le système logique et les noms d’instance de routage si vous souhaitez créer des proxies pour des systèmes logiques ou des instances de routage sur logical-system l’équipement. routing-instance

Remarque :

À partir Junos OS version 15.2, vous devez configurer l’instruction au niveau de la hiérarchie pour interface <interface-name>[edit snmp] l’agent SNMP proxy.

Remarque :

La configuration de la communauté et de la sécurité du proxy doit correspondre à la configuration correspondante sur l’équipement à gérer.

Remarque :

L’agent SNMP proxy n’offre pas de fonctions de trap forwarding, les équipements gérés par l’agent SNMP proxy envoient ces traps directement au système de gestion du réseau.

Vous pouvez utiliser la show snmp proxy commande du mode opérationnel pour afficher les détails du proxy sur un équipement. La commande renvoie les noms de proxy, les show snmp proxy noms des équipements, la version SNMP, la communauté/la sécurité et les informations de contexte.

Configuration des traps SNMP

Les traps sont des messages non sollicités envoyés par un agent SNMP vers des systèmes de gestion du réseau distants ou des récepteurs de trap. De nombreuses entreprises utilisent des traps SNMP dans le cadre d’une solution de surveillance des pannes, en plus de la journalisation système. Dans Junos OS, les traps SNMP ne sont pas transmis par défaut. Vous devez donc configurer un groupe de traps si vous souhaitez utiliser des traps SNMP.

Vous pouvez créer et nommer un groupe d’un ou plusieurs types de traps SNMP, puis définir les systèmes qui reçoivent le groupe de traps SNMP. Le nom du groupe de traps est intégré aux paquets de notification de trap SNMP sous la la mesure d’une liaison variable (varbind) connue sous le nom de la communauté.

Pour configurer un piège SNMP:

  1. Créez une adresse source unique et cohérente qui Junos OS à tous les pièges sortants de votre équipement.

    Une adresse source est utile, car bien que la plupart des équipements Junos OS comptent un certain nombre d’interfaces sortantes, l’utilisation d’une adresse source permet à un NMS distant d’associer la source des pièges à un équipement individuel.

    Cet exemple utilise l’adresse IP de l’interface de bouclage (lo0) comme adresse source de tous les traps SNMP à l’origine de l’équipement.

  2. Créez un groupe de pièges dans lequel vous pouvez énumérer les types de pièges à être transmis et les cibles (adresses) des systèmes de gestion à distance destinataires.

    Cet exemple crée un groupe de trap-group appelé « trap »: il permet d’envoyer des notifications (traps) au format 2 SNMP à l’hôte à l’adresse managers 192.168.1.15. Cette instruction indique toutes les catégories de pièges.

  3. Définir le sous-ensemble spécifique des catégories de pièges à être transmis.

    Pour une liste de catégories, consultez configuring SNMP Trap Groups.

    L’instruction suivante configure les échecs d’MIB-II standard sur l’agent (l’équipement).

  4. Au niveau supérieur de la configuration, appliquez le groupe de configuration.

    Si vous utilisez un groupe de configurations, vous devez l’appliquer pour qu’il prenne effet.

  5. Valider la configuration.
  6. Pour vérifier la configuration, créez un piège d’authentification.

    Cela signifie que l’agent SNMP a reçu une demande auprès d’une communauté inconnue. D’autres types de pièges peuvent également être usurpés.

    Cette fonctionnalité vous permet de déclencher des traps SNMP à partir des routeurs et de vous assurer qu’ils sont correctement traiter dans votre infrastructure de gestion de réseau existante. Cette pratique est également utile pour tester et déboguer le comportement SNMP sur le commutateur ou le NMS.

    À monitor traffic l’aide de la commande, vous pouvez vérifier que le piège est envoyé au système de gestion du réseau.

Configuration des groupes et options de trap SNMP sur un équipement s’exécutant Junos OS

Certains opérateurs ont plusieurs récepteurs trap qui les versent vers un NMS central. Cela permet d’obtenir plusieurs chemins pour les traps SNMP d’un routeur vers le NMS central, via différents récepteurs de traps. Un équipement exécutant Junos OS peut être configuré pour envoyer la même copie de chaque piège SNMP à chaque récepteur de trap configuré dans le groupe de trap.

L’adresse source dans l’en-tête IP de chaque paquet de trap SNMP est définie par défaut à l’adresse de l’interface sortante. Lorsqu’un récepteur de pièges fait avancer le paquet vers le NMS central, l’adresse source est conservée. Le NMS central, en ne regardant que l’adresse source de chaque paquet de trap SNMP, part du principe que chaque piège SNMP vient d’une source différente.

En réalité, les traps SNMP provenaient du même routeur, mais chacun d’entre eux a quitté le routeur via une interface sortante différente.

Les déclarations abordées dans les sections suivantes permettent au NMS de reconnaître les pièges dupliqués et de distinguer les traps SNMPv1 en fonction de l’interface sortante.

Pour configurer les options de trap sNMP et les groupes de trap, inclure les instructions et les instructions au niveau trap-optionstrap-group de la [edit snmp] hiérarchie:

Configuration des options de trap SNMP

À l’aide des options de trap SNMP, vous pouvez définir l’adresse source de chaque paquet de trap SNMP envoyé par le routeur à une adresse unique, indépendamment de l’interface sortante. Vous pouvez également définir l’adresse agent des traps SNMPv1. Pour en savoir plus sur le contenu des traps SNMPv1, consultez la RFC 1157.

Remarque :

Le SNMP ne peut pas être associé à une autre instance de routage que l’instance de routage principale.

Pour configurer les options de trap SNMP, inclure l’instruction au niveau trap-options[edit snmp] de la hiérarchie:

Vous devez également configurer un groupe de traps pour que les options de trap prennent effet. Pour plus d’informations sur les groupes de traps, consultez configuring SNMP Trap Groups.

Ce sujet contient les sections suivantes:

Configuration de l’adresse source pour les traps SNMP

Vous pouvez configurer l’adresse source des paquets pièges de plusieurs manières: lo0, une adresse IPv4 ou une adresse IPv6 valide configurée sur l’une des interfaces du routeur, une adresse système logique ou l’adresse d’une instance de routage. Le lo0 de valeur indique que l’adresse source des paquets de pièges SNMP est définie sur l’adresse de bouclation la plus faible configurée sur le lo0 de l’interface.

Remarque :

Si l’adresse source est une adresse IPv4 ou IPv6 non valide ou n’est pas configurée, des traps SNMP ne sont pas générés.

Vous pouvez configurer l’adresse source des paquets pièges dans l’un des formats suivants:

  • Une adresse IPv4 valide configurée sur l’une des interfaces du routeur

  • Une adresse IPv6 valide configurée sur l’une des interfaces du routeur

  • lo0; c’est-à-dire l’adresse de bouclation la plus faible configurée sur le lo0 d’interface

  • Un nom de système logique

  • Un nom d’instance de routage

Une adresse IPv4 valide comme adresse source

Pour spécifier une adresse d’interface IPv4 valide comme adresse source des traps SNMP sur l’une des interfaces du routeur, inclure l’instruction au niveau de source-address[edit snmp trap-options] la hiérarchie:

address est une adresse IPv4 valide configurée sur l’une des interfaces du routeur.

Une adresse IPv6 valide comme adresse source

Pour spécifier une adresse d’interface IPv6 valide comme adresse source des traps SNMP sur l’une des interfaces du routeur, inclure l’instruction au niveau source-address[edit snmp trap-options] de la hiérarchie:

address est une adresse IPv6 valide configurée sur l’une des interfaces du routeur.

Adresse de bouclation la plus faible en tant qu’adresse source

Pour spécifier l’adresse source des traps SNMP afin qu’ils utilisent l’adresse de bouclisation la plus faible configurée sur l’interface los0 comme adresse source, inclure l’instruction au niveau de la source-address[edit snmp trap-options] hiérarchie:

Pour activer et configurer l’adresse de bouclisation, inclure l’instruction au niveau address[edit interfaces lo0 unit 0 family inet] de la hiérarchie:

Pour configurer l’adresse loopback comme adresse source des paquets pièges:

Dans cet exemple, l’adresse IP 10.0.0.1 est l’adresse source de chaque piège envoyé à partir de ce routeur.

Nom du système logique comme adresse source

Pour spécifier un nom de système logique comme adresse source des traps SNMP, inclure logical-system logical-system-name l’instruction au niveau de la [edit snmp trap-options] hiérarchie.

Par exemple, la configuration suivante définit le nom du système logique comme adresse source des ls1 traps SNMP:

Nom de l’instance de routage comme adresse source

Pour spécifier un nom d’instance de routage comme adresse source des traps SNMP, inclure routing-instance routing-instance-name l’instruction au niveau de la [edit snmp trap-options] hiérarchie.

Par exemple, la configuration suivante définit le nom de l’instance de routage comme adresse source des ri1 traps SNMP:

Configuration de l’adresse agent pour les traps SNMP

L’adresse agent n’est disponible que dans les paquets pièges SNMPv1 (voir RFC 1157). Par défaut, l’adresse locale par défaut du routeur n’est pas spécifiée dans le champ d’adresse agent du trap SNMPv1. Pour configurer l’adresse de l’agent, inclure agent-address l’instruction au niveau [edit snmp trap-options] de la hiérarchie. Actuellement, l’adresse de l’agent ne peut être que l’adresse de l’interface sortante:

Pour configurer l’interface sortante comme adresse de l’agent:

Dans cet exemple, chaque paquet de trap SNMPv1 possède la valeur d’adresse agent définie sur l’adresse IP de l’interface sortante.

Ajout de snmpTrapEnterprise, identifiant d’objet aux traps SNMP standard

L’objet snmpTrapEnterprise vous aide à identifier l’entreprise qui a défini le piège. En général, l’objet snmpTrapEnterprise apparaît comme la dernière varbine dans les traps SNMP de la version 2 de l’entreprise. Cependant, à partir de la version 10.0, Junos OS vous permet d’ajouter l’identifiant d’objet snmpTrapEnterprise aux traps SNMP standard.

Pour ajouter snmpTrapEntreprise aux traps standard, inclure enterprise-oid l’instruction au niveau de la [edit snmp trap-options] hiérarchie. Si enterprise-oid l’instruction n’est pas incluse dans la configuration, snmpTrapEnterprise est uniquement ajouté pour les traps spécifiques à l’entreprise.

Configuration des groupes de traps SNMP

Vous pouvez créer et nommer un groupe d’un ou plusieurs types de traps SNMP, puis définir les systèmes qui reçoivent le groupe de traps SNMP. Le groupe de traps doit être configuré pour que des traps SNMP soient envoyés. Pour créer un groupe de pièges SNMP, inclure l’instruction au trap-group niveau [edit snmp] de la hiérarchie:

Le nom du groupe de trap peut être n’importe quelle chaîne et est intégré au champ de noms de la communauté du piège. Pour configurer votre propre port de groupe de trap, ajoutez destination-port l’instruction. Le port de destination par défaut est le port 162.

Pour chaque groupe de traps que vous définissez, vous devez inclure l’instruction pour définir au moins un système comme destinataire des target traps SNMP du groupe de traps. Indiquez l’adresse IPv4 ou IPv6 de chaque destinataire, et non son nom d’hôte.

Indiquez les types de traps que le groupe de pièges peut recevoir dans categories l’instruction. Pour plus d’informations sur la catégorie à laquelle appartiennent les traps, consultez les traps SNMP standard pris en charge par Junos OS et les traps SNMP spécifiques à l’entreprise Pris en charge Junos OS sujets abordés.

Indiquez l’instance de routage utilisée par le groupe de pièges dans routing-instance l’énoncé. Toutes les cibles configurées dans le groupe de trap utilisent cette instance de routage.

Un groupe de traps peut recevoir les catégories suivantes:

  • authentication—Échecs d’authentification

  • chassis— Notifications de châssis ou d’environnement

  • chassis-cluster— Notifications de mise en cluster

  • configuration— Notifications de configuration

  • link—Notifications liées aux liaisons (transitions en baisse, changement d’état des lignes DS-3 et DS-1, changement d’état de l’interface IPv6 et surcharge pic de surveillance passive)

    Remarque :

    Pour envoyer des traps d’interface surcharge PIC de surveillance passive, sélectionnez la link catégorie de trap.

  • otn-alarms— Sous-catégories des traps d’alarme OTN

  • remote-operations— Notifications d’opérations à distance

  • rmon-alarm—Alarme pour les événements RMON

  • routing—Notifications des protocoles de routage

  • services— Les notifications de services telles que le circuit down ou up, la connexion down ou up, le processeur dépassé, les alarmes et les changements d’état.

  • sonet-alarms—Alarmes SONET/SDH

    Remarque :

    Si vous omettez les sous-catégories SONET/SDH, tous les types d’alarmes de trap SONET/SDH sont inclus dans les notifications de trap.

    • loss-of-light—Perte de notification d’alarme

    • pll-lock—Notification d’alarme de verrouillage PLL

    • loss-of-frame—Notification de perte d’alarme de trame

    • loss-of-signal—Perte de la notification d’alarme de signal

    • severely-errored-frame— Notification d’alarme de trames gravement erronée

    • line-ais—Notification d’alarme de signal d’alarme de ligne (AIS)

    • path-ais—Notification d’alarme PATH AIS

    • loss-of-pointer—Perte de la notification d’alarme de pointeur

    • ber-defect—Notification des défauts d’alarme du taux d’erreur de bits SONET/SDH

    • ber-fault—Notification des anomalies de taux d’erreur SONET/SDH

    • line-remote-defect-indication—Notification de l’alarme de défaillance de la ligne

    • path-remote-defect-indication—Notification de l’alarme de indication de défaillance du chemin à distance

    • remote-error-indication—Notification de l’alarme de indication d’erreur à distance

    • unequipped— Notification d’alarme non-mise en place

    • path-mismatch— Notification d’alarmes d’insaleur de chemin

    • loss-of-cell—Perte de la notification de l’alarme de dlineation de cellule

    • vt-ais—Notification d’alarme AIS virtualisation (VT)

    • vt-loss-of-pointer—Perte VT de la notification d’alarme de pointeur

    • vt-remote-defect-indication—Notification de l’alarme de indication de défaillance à distance VT

    • vt-unequipped—Notification d’alarme sans demande VT

    • vt-label-mismatch— Notification d’erreurs d’insalurance d’étiquettes VT

    • vt-loss-of-cell—Perte de la notification de perte de la dlineation par VT

  • startup— Démarrages réchauffants et peu froids du système

  • timing-events—Notification des événements et défauts de synchronisation

  • vrrp-events—Événements vrRP (Virtual Router Redundancy Protocol) tels que les échecs d’authentification ou les nouvelles méthodes primaires

  • startup— Démarrages réchauffants et peu froids du système

  • vrrp-events—Événements vrRP (Virtual Router Redundancy Protocol) tels que les échecs d’authentification ou les nouvelles méthodes primaires

Si vous comprenez les sous-catégories SONET/SDH, seuls les types d’alarmes de trap SONET/SDH sont inclus dans les notifications de trap.

Cette version instruction vous permet de spécifier la version SNMP des traps envoyés aux cibles du groupe de traps. Si vous v1 spécifiez uniquement, des traps SNMPv1 sont envoyés. Si vous v2 spécifiez uniquement, des traps SNMPv2 sont envoyés. Si vous all spécifiez, un piège SNMPv1 et un piège SNMPv2 sont envoyés pour chaque condition de trap. Pour plus d’informations sur version cet énoncé, consultez la version (SNMP).

Prise en charge des traps SNMP

Les QFX Series des commutateurs, des systèmes QFX Series Virtual Chassis et QFabric autonomes et des systèmes QFabric, prendre en charge des traps SNMP standard et Juniper Networks pièges spécifiques à l’entreprise.

Pour en savoir plus, rendez-vous sur:

Traps SNMP pris en charge par QFX Series et commutateurs autonomes QFX Series Virtual Chassis

QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis prendre en charge les traps SNMPv1 et v2. Pour en savoir plus, rendez-vous sur:

SNMPv1 Traps

QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis prendre en charge des traps SNMPv1 standard et Juniper Networks des traps SNMPv1 spécifiques à l’entreprise. Voir:

  • Tableau 1 pour les traps SNMPv1 standard.

  • Tableau 2 pour les traps SNMPv1 spécifiques aux entreprises.

Les pièges sont organisés d’abord par catégorie de trap, puis par nom de trap. Les niveaux de gravité de la journalisation système sont répertoriés pour les pièges qui les sont. Les traps qui n’ont pas de niveaux de gravité correspondants pour la journalisation du système sont marqués d’un point de contrôle (-).

Tableau 1 : Traps SNMP version 1 standard pris en charge QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis

Défini dans

Nom du piège

ID d’entreprise

Numéro de piège générique

Numéro de piège spécifique

Niveau de gravité de la journalisation système

Étiquette Syslog

Notifications de liens

RFC 1215, Conventions de définition des traps à utiliser avec le SNMP

LinkDown

1.3.6.1.4.1.2636

2

0

Avertissement

SNMP_ TRAP_ LINK_DOWN

Linkup

1.3.6.1.4.1.2636

3

0

Info

SNMP_TRAP_ LINK_UP

Notifications d’opérations à distance

RFC 2925, Définitions des objets gérés pour les opérations ping, traceroute et de recherche distantes

pingProbeFailed

1.3.6.1.2.1.80.0

6

1

Info

SNMP_TRAP 'PING_ PROBE_ ÉCHEC

ping Testé

1.3.6.1.2.1.80.0

6

2

Info

SNMP_TRAP_ PING_TEST _FAILED

pingTest épuisé

1.3.6.1.2.1.80.0

6

3

Info

SNMP_TRAP_ PING_TEST_ TERMINÉ

traceRoutePathChange

1.3.6.1.2.1.81.0

6

1

Info

SNMP_TRAP_ TRACE_ROUTE_ PATH_CHANGE

traceRouteTestFailed

1.3.6.1.2.1.81.0

6

2

Info

SNMP_TRAP_ TRACE_ROUTE_ TEST_FAILED

traceRouteTestCompleted

1.3.6.1.2.1.81.0

6

3

Info

SNMP_TRAP_ TRACE_ROUTE_ TEST_COMPLETED

Alarmes RMON

RFC 2819a, RMON MIB

fallingAlarm (en cours)

1.3.6.1.2.1.16

6

2

risingAlarm

1.3.6.1.2.1.16

6

1

Notifications de routage

BGP 4 MIB

bgpEs en confiance

1.3.6.1.2.1.15.7

6

1

version bgpBackwardTransition

1.3.6.1.2.1.15.7

6

2

OSPF TRAP MIB

ospfVirtIfStateChange

1.3.6.1.2.1.14.16.2

6

1

ospfNbrStateChange

1.3.6.1.2.1.14.16.2

6

2

ospfVirtNbrStateChange

1.3.6.1.2.1.14.16.2

6

3

ospfIfConfigError

1.3.6.1.2.1.14.16.2

6

4

ospfVirtIfConfigError

1.3.6.1.2.1.14.16.2

6

5

ospfIfAuthFailure

1.3.6.1.2.1.14.16.2

6

6

ospfVirtIfAuthFailure

1.3.6.1.2.1.14.16.2

6

7

ospfIfRxBadPacket

1.3.6.1.2.1.14.16.2

6

8

ospfVirtIfRxBadPacket

1.3.6.1.2.1.14.16.2

6

9

ospfTxRetransmit

1.3.6.1.2.1.14.16.2

6

10

ospfVirtIfTxRetransmit

1.3.6.1.2.1.14.16.2

6

11

ospfMaxAgeLsa

1.3.6.1.2.1.14.16.2

6

13

OspfIfStateChange

1.3.6.1.2.1.14.16.2

6

16

Notifications de démarrage

RFC 1215, Conventions de définition des traps à utiliser avec le SNMP

authentificationFailure

1.3.6.1.4.1.2636

4

0

Avis

SNMPD_ TRAP_ GEN_FAILURE

coldStart

1.3.6.1.4.1.2636

0

0

Critique

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.4.1.2636

1

0

Erreur

SNMPD_TRAP_ WARM_START

VRRP Notifications

RFC 2787, Définitions des objets gérés pour le protocole de redondance du routeur virtuel

vrrpTrapNewMaster

1.3.6.1.2.1.68

6

1

Avertissement

VRRPD_NEW MASTER_TRAP

vrrpTrapAuthFailure

1.3.6.1.2.1.68

6

2

Avertissement

VRRPD_AUTH_ FAILURE_TRAP

Tableau 2 : Traps SNMPv1 spécifiques à l’entreprise pris en charge QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis

Défini dans

Nom du piège

ID d’entreprise

Numéro de piège générique

Numéro de piège spécifique

Niveau de gravité de la journalisation système

Balise de journal système

Notifications de châssis (conditions d’alarme)

Châssis MIB (jnx-chassis. mib)

jnxPowerSfeuFailure

1.3.6.1.4.1.2636.4.1

6

1

Avertissement

CHASSISD_ SNMP_ TRAP

jnxAfailure

1.3.6.1.4.1.26361

6

2

Critique

CHASSISD_ SNMP_ TRAP

jnxOverTeature

11.4.1.2636.4.1

6

3

Alerte

CHASSISD_ SNMP_ TRAP

jnxFruRemoval

1.3.6.1.4.1.2636.4.1

6

5

Avis

CHASSISD_ SNMP_ TRAP

jnxFruSétion

1.3.6.1.4.1.2636.4.1

6

6

Avis

CHASSISD_ SNMP_ TRAP

jnxFruPowerOff

1.3.6.1.4.1.2636.4.1

6

7

Avis

CHASSISD_ SNMP_ TRAP

jnxFruPowerOn

1.3.6.1.4.1.2636.4.1

6

8

Avis

CHASSISD_ SNMP_ TRAP

jnxFruFailed

1.3.6.1.4.1.2636.4.1

6

9

Avertissement

CHASSISD_ SNMP_ TRAP

jnxFruOffline

1.3.6.1.4.1.2636.4.1

6

10

Avis

CHASSISD_ SNMP_ TRAP

jnxFruOnline

1.3.6.1.4.1.2636.4.1

6

11

Avis

CHASSISD_ SNMP_ TRAP

jnxFruCheck

1.3.6.1.4.1.2636.4.1

6

12

Avertissement

CHASSISD_ SNMP_ TRAP

jnxPowerSalyOk

1.3.6.1.4.1.2636.4.2

6

1

Critique

CHASSISD_ SNMP_ TRAP

jnxSeok

1.3.6.1.4.1.2636.4.2

6

2

Critique

CHASSISD_ SNMP_ TRAP

jnxTe mêmeatureOK

1.3.6.1.4.1.2636.4.2

6

3

Alerte

CHASSISD_ SNMP_ TRAP

Configuration Notifications

Gestion MIB de configuration (jnx- configmt. mib)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5

6

1

jnxCmRchange

1.3.6.1.4.1.2636.4.5

6

2

Opérations à distance

Ping MIB (jnx-ping.mib)

jnxPingRttThresholdexé

1.3.6.1.4.1.2636.4.9

6

1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

3

jnxPingEgress Que les limites sont dépassées

1.3.6.1.4.1.2636.4.9

6

4

jnxPingÉgressStdDev ThresholdExéded

1.3.6.1.4.1.2636.4.9

6

5

jnxPingEgressJitterDes limites supérieures

1.3.6.1.4.1.2636.4.9

6

6

jnxPingIngresss voir dépassé

1.3.6.1.4.1.2636.4.9

6

7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

8

jnxPingIngressJitterDes limites de participation

1.3.6.1.4.1.2636.4.9

6

9

Alarmes RMON

RMON MIB (jnx-rmon. mib)

jnxRmonAlarmGetFailure

1.3.6.1.4.1.2636.4.3

6

1

jnxRmonGetOk

1.3.6.1.4.1.2636.4.3

6

2

SNMPv2 Traps

  • Tableau 3 répertorie les traps SNMP standard

  • Tableau 4 répertorie Juniper Networks pièges propres à l’entreprise

Tableau 3 : Traps SNMPv2 standard pris en charge QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis

Défini dans

Nom du piège

SNMP Trap OID

Niveau de gravité de la journalisation système

Étiquette Syslog

Notifications de liens

RFC 2863 ( The Interfaces Group MIB

LinkDown

1.3.6.1.6.3.1.1.5.3

Avertissement

SNMP_TRAP_ LINK_DOWN

Linkup

1.3.6.1.6.3.1.1.5.4

Info

SNMP_TRAP_ LINK_UP

Notifications d’opérations à distance

RFC 2925, Définitions des objets gérés pour les opérations ping, traceroute et de recherche distantes

pingProbeFailed

1.3.6.1.2.1.80.0.1

Info

SNMP_TRAP_ PING_PROBE_ ÉCHEC

ping Testé

1.3.6.1.2.1.80.0.2

Info

SNMP_TRAP_PING_ TEST_FAILED

pingTest épuisé

1.3.6.1.2.1.80.0.3

Info

SNMP_TRAP_PING_ TEST_COMPLETED

traceRoutePathChange

1.3.6.1.2.1.81.0.1

Info

SNMP_TRAP_TRACE_ ROUTE_PATH_ LAN

traceRouteTestFailed

1.3.6.1.2.1.81.0.2

Info

SNMP_TRAP_TRACE_ ROUTE_TEST_FAILED

traceRouteTestCompleted

1.3.6.1.2.1.81.0.3

Info

SNMP_TRAP_TRACE_ ROUTE_TEST_ TERMINÉ

Alarmes RMON

RFC 2819a, RMON MIB

fallingAlarm (en cours)

1.3.6.1.2.1.16.0.1

risingAlarm

1.3.6.1.2.1.16.0.2

Notifications de routage

BGP 4 MIB

bgpEs en confiance

1.3.6.1.2.1.15.7.1

version bgpBackwardTransition

1.3.6.1.2.1.15.7.2

OSPF Trap MIB

ospfVirtIfStateChange

1.3.6.1.2.1.14.16.2.1

ospfNbrStateChange

1.3.6.1.2.1.14.16.2.2

ospfVirtNbrStateChange

1.3.6.1.2.1.14.16.2.3

ospfIfConfigError

1.3.6.1.2.1.14.16.2.4

ospfVirtIfConfigError

1.3.6.1.2.1.14.16.2.5

ospfIfAuthFailure

1.3.6.1.2.1.14.16.2.6

ospfVirtIfAuthFailure

1.3.6.1.2.1.14.16.2.7

ospfIfRxBadPacket

1.3.6.1.2.1.14.16.2.8

ospfVirtIfRxBadPacket

1.3.6.1.2.1.14.16.2.9

ospfTxRetransmit

1.3.6.1.2.1.14.16.2.10

ospfVirtIfTxRetransmit

1.3.6.1.2.1.14.16.2.11

ospfMaxAgeLsa

1.3.6.1.2.1.14.16.2.13

OspfIfStateChange

1.3.6.1.2.1.14.16.2.16

Notifications de démarrage

RFC 1907, version base d’informations de gestion version 2 du protocole de gestion de réseau simple (SNMPv2)

coldStart

1.3.6.1.6.3.1.1.5.1

Critique

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.6.3.1.1.5.2

Erreur

SNMPD_TRAP_ WARM_START

authentificationFailure

1.3.6.1.6.3.1.1.5.5

Avis

SNMPD_TRAP_ GEN_FAILURE

VRRP Notifications

RFC 2787, Définitions des objets gérés pour le protocole de redondance du routeur virtuel

vrrpTrapNewMaster

1.3.6.1.2.1.68.0.1

Avertissement

VRRPD_ NEWMASTER_ TRAP

vrrpTrapAuthFailure

1.3.6.1.2.1.68.0.2

Avertissement

VRRPD_AUTH_ FAILURE_ TRAP

Tableau 4 : Traps SNMPv2 spécifiques à l’entreprise pris en charge QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis

Source MIB

Nom du piège

SNMP Trap OID

Niveau de gravité de la journalisation système

Balise de journal système

Notifications sur le châssis (conditions d’alarme)

Châssis MIB (mib-jnx-chassis)

jnxPowerSfeuFailure

1.3.6.1.4.1.2636.4.1.1

Alerte

CHASSISD_ SNMP_ TRAP

 

jnxAfailure

1.3.6.1.4.1.2636.4.1.2

Critique

CHASSISD_ SNMP_ TRAP

 

jnxOverTeature

1.3.6.1.4.1.2636.4.1.3

Critique

CHASSISD_ SNMP_ TRAP

 

jnxFruRemoval

1.3.6.1.4.1.2636.4.1.5

Avis

CHASSISD_ SNMP_ TRAP

 

jnxFruSétion

1.3.6.1.4.1.2636.4.1.6

Avis

CHASSISD_ SNMP_ TRAP

 

jnxFruPowerOff

1.3.6.1.4.1.2636.4.1.7

Avis

CHASSISD_ SNMP_ TRAP

 

jnxFruPowerOn

1.3.6.1.4.1.2636.4.1.8

Avis

CHASSISD_ SNMP_ TRAP

 

jnxFruFailed

1.3.6.1.4.1.2636.4.1.9

Avertissement

CHASSISD_ SNMP_ TRAP

 

jnxFruOffline

1.3.6.1.4.1.2636.4.1.10

Avis

CHASSISD_ SNMP_ TRAP

 

jnxFruOnline

1.3.6.1.4.1.2636.4.1.11

Avis

CHASSISD_ SNMP_ TRAP

 

jnxFruCheck

1.3.6.1.4.1.2636.4.1.12

Avis

CHASSISD_ SNMP_ TRAP

 

jnxPowerSalyOK

1.3.6.1.4.1.2636.4.2.1

Critique

CHASSISD_ SNMP_ TRAP

 

jnxSeok

1.3.6.1.4.1.2636.4.2.2

Critique

CHASSISD_ SNMP_ TRAP

 

jnxTe mêmeatureOK

1.3.6.1.4.1.2636.4.2.3

Alerte

CHASSISD_ SNMP_ TRAP

Configuration Notifications

Gestion MIB de configuration (mib-jnx-cfgmgmt)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5.0.1

jnxCmRchange

1.3.6.1.4.1.2636.4.5.0.2

Notifications d’opérations à distance

Ping MIB (mib-jnx-ping)

jnxPingRtt- Limitez les attentes

1.3.6.1.4.1.2636.4.9.0.1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.3

jnxPingEgress Que les limites sont dépassées

1.3.6.1.4.1.2636.4.9.0.4

jnxPingEgressStdDevThreshold Dépassé

1.3.6.1.4.1.2636.4.9.0.5

jnxPingEgressJitterDes limites supérieures

1.3.6.1.4.1.2636.4.9.0.6

jnxPingIngresss voir dépassé

1.3.6.1.4.1.2636.4.9.0.7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.8

jnxPingIngressJitterDes limites de participation

1.3.6.1.4.1.2636.4.9.0.9

Alarmes RMON

RMON MIB (mib-jnx-rmon)

jnxRmonAlarmGetFailure

1.3.6.1.4.1.2636.4. 3.0.1

jnxRmonGetOk

1.3.6.1.4.1.2636.4. 3.0.2

Traps SNMP pris en charge sur les systèmes QFabric

Les systèmes QFabric supportent des traps SNMPv2 standard et Juniper Networks traps SNMPv2 spécifiques à l’entreprise.

Remarque :

Les systèmes QFabric ne sont pas en charge les traps SNMPv1.

Pour en savoir plus, rendez-vous sur:

  • Tableau 5 pour les traps SNMPv2 standard

  • Tableau 6 pour Juniper Networks pièges SNMPv2 spécifiques à l’entreprise

Tableau 5 : Traps SNMPv2 standard pris en charge sur les systèmes QFabric

Défini dans

Nom du piège

SNMP Trap OID

Niveau de gravité de la journalisation système

Étiquette Syslog

Notifications de liens

RFC 2863 ( The Interfaces Group MIB

LinkDown

1.3.6.1.6.3.1.1.5.3

Avertissement

SNMP_TRAP_ LINK_DOWN

Linkup

1.3.6.1.6.3.1.1.5.4

Info

SNMP_TRAP_ LINK_UP

Notifications de démarrage

RFC 1907, version base d’informations de gestion version 2 du protocole de gestion de réseau simple (SNMPv2)

coldStart

1.3.6.1.6.3.1.1.5.1

Critique

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.6.3.1.1.5.2

Erreur

SNMPD_TRAP_ WARM_START

authentificationFailure

1.3.6.1.6.3.1.1.5.5

Avis

SNMPD_TRAP_ GEN_FAILURE

Tableau 6 : Traps SNMPv2 spécifiques à l’entreprise pris en charge sur les systèmes QFabric

Source MIB

Nom du piège

SNMP Trap OID

Niveau de gravité de la journalisation système

Balise de journal système

Châssis de MIB (mib-jnx-fabric- châssis)

Notifications Sur châssis de structure (conditions d’alarme)

jnxFabricPowerSalyFailure

1.3.6.1.4.1.2636.4.19.1

Avertissement

jnxFabric Grandefailure

1.3.6.1.4.1.2636.4.19.2

Critique

jnxFabricOverTetature

1.3.6.1.4.1.2636.4.19.3

Alerte

jnxFabricRedundancySwitchover

1.3.6.1.4.1.2636.4.19.4

Avis

jnxFabricFruMoval

1.3.6.1.4.1.2636.4.19.5

Avis

jnxFabricFrusertion

1.3.6.1.4.1.2636.4.19.6

Avis

jnxFabricFruPowerOff

1.3.6.1.4.1.2636.4.19.7

Avis

jnxFabricFruPowerOn

1.3.6.1.4.1.2636.4.19.8

Avis

jnxFabricFailed

1.3.6.1.4.1.2636.4.19.9

Avertissement

jnxFabricFruOffline

1.3.6.1.4.1.2636.4.19.10

Avis

jnxFabricFruOnline

1.3.6.1.4.1.2636.4.19.11

Avis

jnxFabricFruCheck

1.3.6.1.4.1.2636.4.19.12

Avertissement

jnxFabricFEBSwitchover

1.3.6.1.4.1.2636.4.19.13

Avertissement

jnxFabricHardDiskFailed

1.3.6.1.4.1.2636.4.19.14

Avertissement

jnxFabricHardDiskMissing

1.3.6.1.4.1.2636.4.19.15

Avertissement

jnxFabricBootDebackup

1.3.6.1.4.1.2636.4.19.16

Avertissement

Notifications de châssis de structure (conditions d’autorisation d’alarme)

jnxFabricPowerSalyOK

1.3.6.1.4.1.2636.4.20.1

Critique

jnxFabricSeok

1.3.6.1.4.1.2636.4.20.2

Critique

jnxFabricTeaatureOK

1.3.6.1.4.1.2636.4.20.3

Alerte

jnxFabricFruOK

1.3.6.1.4.1.2636.4.20.4

QFabric MIB (mib-jnx-qf-smi)

QFabric MIB Notifications

jnxQFabricDownloadé

1.3.6.1.4.1.2636.3.42.1.0.1

jnxQFabricDownfailed

1.3.6.1.4.1.2636.3.42.1.0.2

jnxQFabricDownloadsucceed

1.3.6.1.4.1.2636.3.42.1.0.3

jnxQFabricUpgradeSued

1.3.6.1.4.1.2636.3.42.1.0.4

jnxQFabricUpgradeFailed

1.3.6.1.4.1.2636.3.42.1.0.5

jnxQFabric Niveau de suivi

1.3.6.1.4.1.2636.3.42.1.0.6

Configuration Notifications

Gestion MIB de configuration (mib-jnx-cfgmgmt)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5.0.1

jnxCmRchange

1.3.6.1.4.1.2636.4.5.0.2

Notifications d’opérations à distance

Ping MIB (mib-jnx-ping)

jnxPingRtt- Limitez les attentes

1.3.6.1.4.1.2636.4.9.0.1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.3

jnxPingEgress Que les limites sont dépassées

1.3.6.1.4.1.2636.4.9.0.4

jnxPingEgressStdDevThreshold Dépassé

1.3.6.1.4.1.2636.4.9.0.5

jnxPingEgressJitterDes limites supérieures

1.3.6.1.4.1.2636.4.9.0.6

jnxPingIngresss voir dépassé

1.3.6.1.4.1.2636.4.9.0.7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.8

jnxPingIngressJitterDes limites de participation

1.3.6.1.4.1.2636.4.9.0.9

Exemple: Configuration des groupes de traps SNMP

Configurer une liste de notifications pièges nommée pour les pièges de lien urgent-dispatcher et de démarrage. Cette liste permet d’identifier les hôtes de gestion du réseau (et) les pièges générés par le 1.2.3.4fe80::1:2:3:4 routeur local. Le nom indiqué pour un groupe de trap est utilisé comme chaîne de la communauté SNMP lorsque l’agent envoie des pièges aux cibles répertoriées.

Configuration des interfaces sur lesquelles les requêtes SNMP peuvent être acceptées

Par défaut, toutes les interfaces de routeur ou de commutation ont des droits d’accès SNMP. Pour limiter l’accès via certaines interfaces uniquement, inclure l’instruction au niveau interface[edit snmp] de la hiérarchie:

Indiquez le nom des interfaces physiques ou logiques qui devraient avoir des privilèges d’accès SNMP. Toutes les requêtes SNMP entrant dans le routeur ou le commutateur à partir d’interfaces non répertoriées sont écartées.

Exemple: Configuration de la liste d’accès sécurisé

Les privilèges d’accès SNMP sont accordés aux seuls équipements se s’erant sur les interfaces so-0/0/0 et at-1/0/1 . Pour cela, l’exemple suivant configure une liste d’interfaces logiques:

L’exemple suivant accorde le même accès en configurant une liste d’interfaces physiques:

Informations de l’interface de filtrage hors sortie de SNMP Sortie Get and GetNext

Junos OS vous permet de filtrer les informations relatives aux interfaces spécifiques à partir de la sortie de SNMP et des requêtes exécutées sur des MB liés aux GetGetNext interfaces, comme IF MIB, ATM MIB, RMON MIB et l’IF MIB spécifique à l’entreprise Juniper Networks.

Vous pouvez utiliser les options suivantes de l’instruction au niveau de la hiérarchie pour spécifier les interfaces que vous souhaitez exclure de filter-interfaces[edit snmp] SNMP et des GetGetNext requêtes:

  • interfaces—Interfaces qui correspondent aux expressions régulières spécifiées.

  • all-internal-interfaces— Interfaces internes.

À partir de la version 12.1, Junos OS fournit une option sauf (opérateur) qui vous permet de filtrer toutes les interfaces, à l’exception des interfaces qui correspondent à toutes les expressions régulières préfixées avec la !! marque.

Par exemple, pour filtrer toutes les interfaces, à l’exception des interfaces du SNMP et des résultats, saisissez geget la commande get-next suivante:

Lorsque cette configuration est configurée, Junos OS toutes les interfaces, à l’exception des interfaces du ge SNMP get et des get-next résultats.

Remarque :

La ! marque n’est prise en charge que comme premier caractère de l’expression régulière. Si l’expression est régulière, Junos OS considère que l’expression régulière n’est pas valable et renvoie une erreur.

Cependant, notez que ces paramètres sont limités aux opérations SNMP et que les utilisateurs peuvent continuer à accéder aux informations liées aux interfaces (y compris celles cachées à l’aide des commandes de Junos OS interface de ligne de commande filter-interfaces (CLI).

Configuration des MIB vues

SNMPv3 définit le concept de vues MIB dans le RFC 3415, View-based Access Control Model (VACM) pour le protocole SNMP (Simple Network Management Protocol). MIB vues fournit à l’agent un meilleur contrôle des accès à des filiales et des objets spécifiques au sein de MIB arborescence. Une vue se compose d’un nom et d’un ensemble d’identifiants d’objets SNMP, qui sont explicitement inclus ou exclu. Une fois définie, une vue est ensuite attribuée à un groupe SNMPv3 ou à une communauté SNMPv1/v2c (ou plusieurs communautés), ce qui masque automatiquement les parties des MIB tree des membres du groupe ou de la communauté peuvent (ou ne peuvent pas) accéder.

Par défaut, la communauté SNMP accorde l’accès en lecture et refuse l’accès à l’ensemble des MIB pris en charge (même les communautés configurées en authorization read-write tant que). Pour restreindre ou accorder la lecture ou l’écriture d’un accès à un ensemble d’MIB, vous devez configurer une vue d MIB et associer cette vue à une communauté.

Pour configurer les vues MIB, inclure view l’instruction au niveau de la [edit snmp] hiérarchie:

viewL’énoncé définit une MIB et identifie un groupe d’MIB objets. Chaque MIB objet d’une vue est préfixe d’objet commun. Chaque identifiant d’objet représente un sous-tree de la hiérarchie MIB objet. Le sous-arbre peut être représenté soit par une séquence d’tegers en pointillés (tels que) soit par son nom 1.3.6.1.2.1.2 sous-tree (par interfaces exemple). Une instruction de configuration utilise une vue pour spécifier un groupe d’MIB sur lesquels définir l’accès. Vous pouvez également utiliser un caractère générique astérisque (*) pour inclure des ONI qui correspondent à un motif particulier dans la vue SNMP. Pour qu’une vue soit en place, vous devez l’associer à la communauté.

Pour supprimer complètement une OID, utilisez la delete view all oid oid-number commande, mais n’utilisez pas les include paramètres.

L’exemple suivant crée une MIB que l’on appelle ping-mib-view. L’énoncé ne nécessite pas de point au début de oid l’identifiant d’objet. snmp viewL’instruction inclut la filiale sous l’identifiant d’objet .1.3.6.1.2.1.80. Cela inclut l’ensemble des sous-trees DISMAN-PINGMIB (tels que définis dans le RFC 2925, Définitions des objets gérés pour les opérations de ping distant, tracerouteet de recherche), ce qui permet d’accéder à n’importe quel objet sous cette filiale.

L’exemple suivant ajoute une seconde filiale dans la même MIB vue.

Attribuez une MIB à la communauté que vous souhaitez contrôler.

Pour associer MIB points de vue d’une communauté, inclure view l’énoncé au niveau de la [edit snmp community community-name] hiérarchie:

Pour plus d’informations sur le ping MIB, consultez les exemples RFC 2925 et PING MIB.

Configuration du proxy ping MIB

Limiter la communauté ping-mib pour lire et écrire l’accès au ping MIB jnxpingMIB et uniquement. Lire ou écrire un accès à n’importe MIB en utilisant cette communauté n’est pas autorisé.

La configuration suivante empêche la communauté no-ping-mib d’accéder aux MIB ping jnxPingMIB et aux objets. Cependant, cette configuration n’empêche pas la communauté no-ping-mib d’accéder à n’importe MIB objet connecté à l’équipement.

Comprendre l’interface de gestion locale intégrée

L’interface de gestion locale intégrée (ILMI) fournit un mécanisme pour les équipements connectés en mode de transfert asynchrone, tels que les hôtes, les routeurs et les commutateurs ATM, afin de transférer les informations de gestion. ILMI fournit un échange bidirectionnel d’informations de gestion entre deux interfaces ATM sur une connexion physique. Les informations ILMI sont échangées en échange d’une encapsulation directe de SNMP version 1 (RFC 1157, A Simple Network Management Protocol)sur une adaptation atm de couche 5 (AAL5) à l’aide d’un identifiant de chemin virtuel/identifiant de canal virtuel (VPI/VCI) valeur (VPI=0, VCI=16).

Junos OS prend en charge seulement deux variables de MIB ILMI: atmfMYIPNmAddress et atmfPortMyIfname . Pour les interfaces intelligentes de mise en file d’utilisateur (IQ) ATM1 et ATM2, vous pouvez configurer ILMI pour communiquer directement avec un commutateur ATM connecté afin d’interroger l’adresse IP et le numéro de port du commutateur.

Pour plus d’informations sur le MIB ILMI, consultez ou atmfMYIPNmAddress dans atmfPortMyIfname le SNMP MIB Explorer.

Service public MIB

L’Juniper Networks utility MIB d’entreprise, dont l’ID d’objet est {jnxUtilMibRoot 1}, définit les objets pour les compteurs, les registres et les chaînes. Le service public MIB un tableau pour chacun des cinq types de données suivants:

  • Compteurs 32 bits

  • Compteurs 64 bits

  • Registres signés

  • Registres non signés

  • Chaînes d’octet

Chaque type de données possède un nom ASCII arbitraire, qui est défini lorsque les données sont peuplées, et un point d’affiche affiche la dernière fois lorsque l’instance de données a été modifiée. Pour obtenir une version téléchargeable de ce MIB, consultez le Guide de l’utilisateur stratégies de routage, filtresde pare-feu et policeurs du trafic.

Pour plus d’informations sur les objets des MIB des entreprises, consultez les sujets suivants:

Prise en charge des MB SNMP

Les QFX Series, les systèmes QFX Series Virtual Chassis et QFabric autonomes et les systèmes MIM et QFabric Juniper Networks mimiques d’entreprise spécifiques.

Remarque :

Pour plus d’informations sur les objets d’MIB SNMP spécifiques à l’entreprise, consultez le SNMP MIB Explorer. Vous pouvez utiliser SNMP MIB Explorer pour afficher des informations sur divers MBIT, objets MIB et notifications SNMP pris en charge sur Juniper Networks périphériques

Pour en savoir plus, rendez-vous sur:

MBIT/s pris en charge sur les QFX Series et les commutateurs autonomes QFX Series Virtual Chassis

Les QFX Series et les commutateurs autonomes QFX Series Virtual Chassis prendre en charge à la fois les MIM standard et Juniper Networks MIM spécifiques à l’entreprise. Pour en savoir plus, rendez-vous sur:

  • Tableau 7 pour les MIM standard.

  • Tableau 8 pour Juniper Networks MIM spécifiques à l’entreprise.

Tableau 7 : MIM standard pris en charge sur QFX Series et commutateurs autonomes QFX Series Virtual Chassis

Rfc

Informations supplémentaires

IEEE section 802.1ab 12.1, protocole LLDP (Link Layer Discovery Protocol) MIB

Tables et objets pris en charge:

  • lldpRemManAddrOID

  • lldpLocManAddrOID

  • lldpReisDelay

  • lldpNotificationInterval

  • lldpStatsRxPortFramesDiscardedTotal

  • lldpStatsRxPortFramesError

  • lldpStatsRxPortTLVsDiscardedTotal

  • lldpStatsRxPortTLVsUnresponsableTotal

  • lldpStatsRxPortAgeoutsTotal

IEEE 802.3ad, agrégation de plusieurs segments de liaisons

Les tableaux et objets suivants sont pris en charge:

  • dot3adAggPortTable, dot3adAggPortListTable, dot3adAggTable et dot3adAggPortStatsTable

  • dot3adAggPortDebugTable (uniquement dot3adAggPortBugRxState, dot3adAggPortDebugMuxState, dot3adAggPortAbugActorSyncTransitionCount, dot3adAggPortDebugPartnerSyncTransitionCount, dot3adAggPortDebugActorChangeCount et dot3adAggPortDebugPartnerChangeCount)

  • dot3adTablesLastChanged

RFC 1155, Structure et identification des informations de gestion pour les réseaux Internet basés sur TCP/IP

RFC 1157, A Simple Network Management Protocol (SNMP)

RFC 1212, Définitions MIB concises

RFC 1213, base d’informations de gestion pour la gestion du réseau des réseaux Internet basés sur TCP/IP: MIB-II

Les domaines suivants sont pris en charge:

  • MIB II et ses dérivés SNMP version 2, notamment:

    • Compteurs de statistiques

    • IP, sauf ipRouteTable, qui a été remplacé par IPCidrRouteTable (RFC 2096, IP Forwarding Table MIB)

    • IpAddrTable

    • Gestion SNMP

    • Gestion des interfaces

  • SNMPv1 Get , requêtes et demandes de GetNext SNMPv2 GetBulk

  • Junos OS une liste d’accès sécurisé spécifique

  • Mots-clés de configuration maître

  • Reconfigurations sur SIGHUP

RFC 1215, Convention de définition des traps à utiliser avec le SNMP

La prise en charge est limitée à MIB traps SNMP II version 1 et aux notifications de la version 2.

RFC 1286, Définitions des objets gérés pour les ponts

RFC 1657, Définitions des objets gérés pour la quatrième version du Border Gateway Protocol (BGP-4) avec SMIv2

RFC 1850, OSPF version 2 base d’informations de gestion

Le tableau, les objets et les traps suivants ne sont pas pris en charge:

  • Tableau hôte

  • ospfOriginateNewLsas et ospfRxNewLsas objets

  • ospfOriginateLSA, ospfLsdbOverflow et ospfLsdbApproachingOverflow traps

RFC 1901, Introduction à la technologie SNMPv2 basée sur la communauté

RFC 1905, Opérations de protocole pour la version 2 du protocole de gestion de réseau simple (SNMPv2)

RFC 1907, version base d’informations de gestion version 2 du protocole de gestion de réseau simple (SNMPv2)

RFC 2011 , SNMPv2 base d’informations de gestion pour le protocole Internet utilisant SMIv2

RFC 2012 Le protocole SNMPv2 base d’informations de gestion pour le protocole de contrôle de transmission utilisant SMIv2

RFC 2013 Le protocole SNMPv2 base d’informations de gestion du protocole User Datagram Protocol using SMIv2

RFC 2233 Le groupe d’interfaces MIB SMIv2

Remarque :

Le RFC 2233 a été remplacé par le RFC 2863. Toutefois, Junos OS prend en charge à la fois RFC 2233 et RFC 2863.

RFC 2287, Définitions des objets gérés au niveau système pour applications

Les objets suivants sont pris en charge:

  • sysApplInstallPkgTable

  • sysApplInstallEltable

  • sysApplEllomrunTable

  • sysApplMapTable

RFC 2570, Introduction à la version 3 de l’infrastructure de gestion de réseau internet standard

RFC 2571, An Architecture for Describing SNMP Management Frameworks (accès en lecture seule)

Remarque :

Le RFC 2571 a été remplacé par le RFC 3411. Toutefois, Junos OS prend en charge à la fois RFC 2571 et RFC 3411.

RFC 2572, Traitement et distribution des messages pour le protocole SNMP (Simple Network Management Protocol) (accès en lecture seule)

Remarque :

Le RFC 2572 a été remplacé par le RFC 3412. Toutefois, Junos OS prend en charge à la fois RFC 2572 et RFC 3412.

RFC 2576, coexistence entre la version 1, la version 2 et la version 3 de l’infrastructure de gestion du réseau selon le standard Internet

Remarque :

Le RFC 2576 a été remplacé par le RFC 3584. Toutefois, Junos OS prend en charge à la fois RFC 2576 et RFC 3584.

RFC 2578, Structure des informations de gestion version 2 (SMIv2)

RFC 2579, Conventions de texte pour SMIv2

RFC 2580, Déclarations de conformité pour SMIv2

RFC 2665, Définitions des objets gérés pour les types d’interfaces Ethernet

RFC 2787, Définitions des objets gérés pour le protocole de redondance du routeur virtuel

La prise en charge n’inclut pas la création de lignes, l’exploitation de l’ensemble et l’objet vrrpStatsPacketLengthErors.

RFC 2790, ressources hôtes MIB

La prise en charge est limitée aux objets suivants:

  • HrStorageTable uniquement. Les systèmes de / fichiers /config , et /var/tmp renvoyent toujours le même numéro d’index. Lorsque SNMP redémarre, les numéros d’index des systèmes de fichiers restants peuvent changer.

  • Seuls les objets des groupes hrSystem et hrSWInstalled.

RFC 2819, Surveillance de réseau à distance base d’informations de gestion

Les objets suivants sont pris en charge:

  • etherStatsTable (pour les interfaces Ethernet uniquement), alarmTable, eventTable et logTable.

  • historiqueControlTable et etherHistoryTable (à l’exception de l’objet etherHistoryUtilization).

RFC 2863 ( The Interfaces Group MIB

Remarque :

Le RFC 2233 a été remplacé par le RFC 2863. Toutefois, Junos OS prend en charge à la fois RFC 2233 et RFC 2863.

RFC 2932, Routage multicast IPv4 MIB

RFC 2933, protocole IGMP (Internet Group Management Protocol) MIB

RFC 2934, multicast indépendant du MIB protocole pour IPv4

En Junos OS, le RFC 2934 est implémenté sur la base d’une version préliminaire, pimmib.mib, de la norme RFC actuelle.

RFC 3410, Déclarations d’introduction et d’application pour le cadre de gestion des normes Internet

RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks (Protocole de gestion de réseau simple)

Remarque :

Le RFC 3411 remplace le RFC 2571. Toutefois, Junos OS prend en charge à la fois la RFC 3411 et la RFC 2571.

RFC 3412, Traitement et distribution des messages pour le protocole SNMP (Simple Network Management Protocol)

Remarque :

Le RFC 3412 remplace le RFC 2572. Toutefois, Junos OS prend en charge à la fois la RFC 3412 et la RFC 2572.

RFC 3413 Applications SNMP (Simple Network Management Protocol)

Toutes les MBIT sont pris en charge, à l’exception du proxy MIB.

RFC 3414, UsM (User-based Security Model) pour la version 3 du protocole SNMPv3 (Simple Network Management Protocol)

RFC 3415, Modèle de contrôle d’accès basé sur la vue (VACM) pour le protocole SNMP (Simple Network Management Protocol)

RFC 3416, version 2 des opérations de protocole pour le protocole de gestion de réseau simple (SNMP)

Remarque :

Le RFC 3416 remplace la RFC 1905, prise en charge dans les versions antérieures de Junos OS.

RFC 3417, Mappages de transport pour le protocole SNMP (Simple Network Management Protocol)

RFC 3418, base d’informations de gestion (MIB) pour le protocole SNMP (Simple Network Management Protocol)

Remarque :

Le RFC 3418 remplace la RFC 1907, prise en charge dans les versions antérieures de Junos OS.

RFC 3584, coexistence entre la version 1, la version 2 et la version 3 de l’infrastructure de gestion du réseau selon le standard Internet

RFC 3826, Algorithme de chiffrement AES (Advanced Encryption Standard) dans le modèle de sécurité basé sur l’utilisateur SNMP

RFC 4188, Définitions des objets gérés pour les ponts

Les QFX3500 et QFX3600 sont uniquement en charge de la 802.1D STP (1998) et des objets et sous-arbres suivants:

  • dot1dTp soustree: objets dot1dTpFdbAddress, dot1dTpFdbPort et dot1dTpFdbStatus de la table dot1dTpFdbTable.

  • dot1dBase soustree— objets dot1dBasePort et dot1dBasePortIfIndex de la table dot1dBasePortTable.

Remarque :

Sur QFX3500 et QFX3600, la table dot1dTpFdbTable n’est remplie que d’adresses MAC apprises sur le VLAN par défaut. Pour voir les adresses MAC de tous les VLAN, indiquez la table dot1qTpFdbTable (RFC 4363b, MIB VLAN Q-Bridge)lors de l’émission de la show snmp mib walk commande.

Non pris en charge sur les équipements OCX Series.

RFC 4293, base d’informations de gestion pour le protocole Internet (IP)

Prend en charge la table ipAddrTable uniquement.

RFC 4318, Définitions des objets gérés pour les ponts avec rapid spanning tree protocol

Prend en charge les extensions 802.1w et 802.1t pour RSTP.

Non pris en charge sur les équipements OCX Series.

RFC 4363b, VLAN Q-Bridge MIB

Remarque :

Sur les commutateurs QFX3500 et QFX3600, la table dot1dTpFdbTable (RFC 4188, Definitions of Managed Objects for Bridges)est uniquement remplie d’adresses MAC apprises sur le VLAN par défaut. Pour voir les adresses MAC de tous les VLAN, indiquez le tableau dot1qTpFdbTable (dans cette MIB) lorsque vous émettrez la show snmp mib walk commande.

Non pris en charge sur les équipements OCX Series.

RFC 4444, IS-IS MIB

Internet Assigned Numbers Authority, convention de texte IANAifType MIB (référencée par RFC 2233)

Voir http://www.iana.org/assignments/ianaiftype-mib .

Projet Internet draft-reeder-snmpv3-usm-3desede-00.txt, Extension to the User-Based Security Model (USM) to Support Triple-DES EDE in 'Outside' JET Mode

Projet Internet draft-ietf-idmr-igmp-mib-13.txt, igMP (Internet Group Management Protocol) MIB

ESO Consortium MIB

Remarque :

Le pare-MIB ESO Consortium a été remplacé par le RFC 3826. Voir http://www.snmp.com/eso/.

Tableau 8 : Juniper Networks MIM spécifiques à l’entreprise pris en charge QFX Series commutateurs et commutateurs autonomes QFX Series Virtual Chassis

MIB

Description

Alarme MIB (alarme mib-jnx-chassis-)

Prise en charge des alarmes du commutateur.

Analyseur MIB (mib-jnx-analyzer)

Contient des données d’analyseur et d’analyse à distance liées à la mise en miroir des ports.

Non pris en charge sur les équipements OCX Series.

Châssis MIB (mib-jnx-chassis)

Assure une prise en charge de la surveillance environnementale (état du câble d’alimentation, tensions de carte, ventilateurs, températures et flux d’air) et une prise en charge d’inventaire du châssis, des concentrateurs PIC flexibles (FPPC) et des PIC.

Remarque :

La table jnxLEDTable a été dépréciée.

Définitions de châssis pour les MIB routeurs (définitions du mib-jnx-chas)

Contient les identificateurs d’objets (OID) utilisés par le système de MIB pour identifier les plates-formes de routage et de commutation et les composants du châssis. Le châssis MIB des informations qui changent souvent, alors que les définitions de châssis pour le modèle de routeur MIB fournissent des informations qui changent moins souvent.

Classe de service MIB (mib-jnx-cos)

Fournit une prise en charge de la surveillance des statistiques de la file d’attente de sortie de l’interface par interface et par classe de forwarding.

Gestion MIB de configuration (mib-jnx-cfgmgmt)

Notification des changements de configuration et des changements de configuration de sauvetage sous la forme de traps SNMP. Chaque piège contient l’heure à laquelle la modification de configuration a été commise, le nom de l’utilisateur qui a effectué la modification et la méthode par laquelle la modification a été faite.

L’historique des 32 dernières modifications de configuration est conservée dans jnxCmChgEventTable.

Mac Ethernet MIB (mib-jnx-mac)

Surveille adresse MAC (MAC) sur les interfaces intelligentes de mise en file d’utilisateur (IQ) Gigabit Ethernet. Il collecte des statistiques MAC; inoctets, interne, outoctets et outframes sur chaque adresse MAC source et ID LAN virtuel (VLAN) pour chaque port Ethernet.

Non pris en charge sur les équipements OCX Series.

Événement MIB (mib-jnx-event)

Définit un piège générique qui peut être généré à l’aide d’un script d’opérations ou d’une stratégie d’événement. Cette MIB permet de spécifier une chaîne de journaux système et de lever un piège si cette chaîne de journal système est trouvée.

Dans Junos OS version 13.2X51-D10 ou ultérieure, si vous avez configuré une stratégie d’événement pour élever un piège en cas d’ajout d’une nouvelle cible de trap SNMP, le piège SNMPD_TRAP_TARGET_ADD_NOTICE est généré avec des informations sur la nouvelle cible.

Sécurité MIB pare-feu (mib-jnx-firewall)

Prise en charge de la surveillance des compteurs de filtres de pare-feu.

Ressources hôtes MIB (mib-jnx-hostresources)

Étend l’objet hrStorageTable, en fournissant une mesure en pourcentage de l’utilisation de chaque système de fichiers sur le commutateur. Auparavant, les objets du hrStorageTable mesuraient l’utilisation dans les unités d’allocation (hrStorageUsed et hrStorageAllocationUnits) uniquement. La mesure du pourcentage vous permet de surveiller et d’appliquer plus facilement des seuils d’utilisation.

Interface MIB (extensions) (extensions mib-jnx-if)

Étend la norme ifTable (RFC 2863) avec des statistiques supplémentaires et Juniper Networks des informations sur les châssis spécifiques à l’entreprise dans les tables ifJnxTable et ifChassisTable.

MIB L2ALD (mib-jnx-l2ald)

Fournit des informations sur l’apprentissage des adresses de couche 2 et sur les pièges connexes, tels que le piège de limite MAC de l’instance de routage et le trap de limite MAC de l’interface. Cette MIB fournit également des informations sur le VLAN dans la table jnxL2aldVlanTable pour les commutateurs de EX Series et de QFX Series couche 2 améliorée.

Remarque :

Les commutateurs EX Series VLAN utilisent la MIB VLAN (jnxExVlanTable) pour obtenir des informations sur le VLAN plutôt que MIB.

MPLS MIB (mib-jnx-mpls)

Fournit des MPLS et définit MPLS notifications.

Remarque :

Cette MIB n’est pas prise en charge par QFX5100 commutateur.

MPLS de MIB LDP (mib-jnx-mpls-ldp)

Contient des définitions d’objets telles que décrites dans le RFC 3815, Definitions of Managed Objects for the MPLS (MPLS), Label Distribution Protocol (LDP).

Remarque :

Cette MIB n’est pas prise en charge par QFX5100 commutateur.

Ping MIB (mib-jnx-ping)

Étend la table de MIB ping standard (RFC 2925). Les éléments de ce MIB sont créés lorsque les entrées sont créées dans pingCtlTable du ping MIB. Chaque élément est indexé exactement comme il se trouve dans le ping MIB.

Événements et alarmes RMON MIB (mib-jnx-rmon)

Prend Junos OS des extensions de la norme RMON (Remote Monitoring) Événements et alarmes MIB (RFC 2819). L’extension augmente l’objet alarmtable avec des informations supplémentaires sur chaque alarme. Deux pièges supplémentaires sont également définis pour indiquer les problèmes rencontrés lors d’une alarme.

Structure des informations de MIB (mib-jnx-smi)

Explique comment les MIM Juniper Networks’entreprise sont structurées.

Journal MIB système (mib-jnx-syslog)

Permet la notification d’une application basée sur un piège SNMP lorsqu’un message de journal système important se produit.

Service public MIB (mib-jnx-util)

Fournit SNMP et MIB des conteneurs des types suivants: Compteurs 32 bits, compteurs 64 bits, registres signés, octet et chaînes d’octet non signées. Vous pouvez utiliser ces objets pour stocker des données qui peuvent être récupérées à l’aide d’autres opérations SNMP.

MIB VLAN (mib-jnx-vlan)

Contient des informations sur les IEEE VLAN 802.10 et leur association avec les clients d’émulation LAN.

Remarque :

Pour les commutateurs ELS EX Series et les commutateurs QFX Series, les informations sur le VLAN sont disponibles dans la MIB L2ALD de la table jnxL2aldVlanTable et non dans la MIB VLAN Pour les commutateurs EX Series non ELS, les informations VLAN sont fournies dans le MIB VLAN de la table jnxExVlanTable.

Non pris en charge sur les équipements OCX Series.

MBITS pris en charge sur les systèmes QFabric

Les systèmes QFabric s’appuient à la fois sur des MIM standard et Juniper Networks MIM spécifiques à l’entreprise. Pour en savoir plus, rendez-vous sur:

  • Tableau 9 pour les MIM standard.

  • Tableau 10 pour Juniper Networks MIM spécifiques à l’entreprise.

Tableau 9 : MIM standard pris en charge sur les systèmes QFabric

Rfc

Informations supplémentaires

RFC 1155, Structure et identification des informations de gestion pour les réseaux Internet basés sur TCP/IP

RFC 1157, A Simple Network Management Protocol (SNMP)

RFC 1212, Définitions MIB concises

RFC 1213, base d’informations de gestion pour la gestion du réseau des réseaux Internet basés sur TCP/IP: MIB-II

Les domaines suivants sont pris en charge:

  • MIB II et ses dérivés SNMP version 2, notamment:

    • Compteurs de statistiques

    • IP, sauf ipRouteTable, qui a été remplacé par IPCidrRouteTable (RFC 2096, IP Forwarding Table MIB)

    • IpAddrTable

    • Gestion SNMP

    • Gestion des interfaces

  • SNMPv1 Get , requêtes et requête de version GetNext 2 GetBulk

  • Junos OS une liste d’accès sécurisé spécifique

  • Mots-clés de configuration maître

  • Reconfigurations sur SIGHUP

RFC 1215, Convention de définition des traps à utiliser avec le SNMP

La prise en charge est limitée à MIB traps SNMP II version 1 et aux notifications de la version 2.

RFC 1286, Définitions des objets gérés pour les ponts

RFC 1901, Introduction à la technologie SNMPv2 basée sur la communauté

RFC 1905, Opérations de protocole pour la version 2 du protocole de gestion de réseau simple (SNMPv2)

RFC 1907, version base d’informations de gestion version 2 du protocole de gestion de réseau simple (SNMPv2)

RFC 2011 , SNMPv2 base d’informations de gestion pour le protocole Internet utilisant SMIv2

Remarque :

Sur le système QFabric, pour que la demande de mise en pratique du protocole SNMP fonctionne, vous devez configurer l’adresse IP d’au moins une interface en plus des interfaces Ethernet de gestion (me0 et me1) du groupe Director.

RFC 2012 Le protocole SNMPv2 base d’informations de gestion pour le protocole de contrôle de transmission utilisant SMIv2

RFC 2013 Le protocole SNMPv2 base d’informations de gestion du protocole User Datagram Protocol using SMIv2

RFC 2233 Le groupe d’interfaces MIB SMIv2

Remarque :

Le RFC 2233 a été remplacé par le RFC 2863. Toutefois, Junos OS prend en charge à la fois RFC 2233 et RFC 2863.

Remarque :

Le système QFabric ne prend en charge que les objets suivants: ifNumber, ifTable et ifxTable.

RFC 2571, An Architecture for Describing SNMP Management Frameworks (accès en lecture seule)

Remarque :

Le RFC 2571 a été remplacé par le RFC 3411. Toutefois, Junos OS prend en charge à la fois RFC 2571 et RFC 3411.

RFC 2572, Traitement et distribution des messages pour le protocole SNMP (Simple Network Management Protocol) (accès en lecture seule)

Remarque :

Le RFC 2572 a été remplacé par le RFC 3412. Toutefois, Junos OS prend en charge à la fois RFC 2572 et RFC 3412.

RFC 2576, coexistence entre la version 1, la version 2 et la version 3 de l’infrastructure de gestion du réseau selon le standard Internet

Remarque :

Le RFC 2576 a été remplacé par le RFC 3584. Toutefois, Junos OS prend en charge à la fois RFC 2576 et RFC 3584.

RFC 2578, Structure des informations de gestion version 2 (SMIv2)

RFC 2579, Conventions de texte pour SMIv2

RFC 2580, Déclarations de conformité pour SMIv2

RFC 2665, Définitions des objets gérés pour les types d’interfaces Ethernet

Le système QFabric prend en charge les tableaux suivants uniquement:

  • dot3StatsTable: il existe une ligne avec les statistiques de chaque interface Ethernet dans le système QFabric. Dot3StatsIndex est un index d’interface unique à l’ensemble du système.

  • dot3ControlTable: cette table est chacune d’une ligne pour chaque interface De la qualité Ethernet du système QFabric qui implémente la couche sous-couche de contrôle MAC. Les OID pris en charge sont dot3ControlFunctionsSupportés et dot3ControlInUnknownOpcode.

  • dot3PauseTable: cette table prend en charge une ligne pour chaque interface Ethernet du système QFabric qui prend en charge la fonction PAUSE de contrôle MAC. Les OID pris en charge sont dot3PauseAdminMode, dot3PauseOperMode, dot3InPauseFrames et dot3OutPauseFrames.

Remarque :

Les variables évolutives ne sont pas pris en charge par le système QFabric.

RFC 2863 ( The Interfaces Group MIB

Remarque :

Le RFC 2233 a été remplacé par le RFC 2863. Toutefois, Junos OS prend en charge à la fois RFC 2233 et RFC 2863.

Remarque :

Le système QFabric ne prend en charge que les objets suivants: ifNumber, ifTable et ifxTable.

RFC 2933, protocole IGMP (Internet Group Management Protocol) MIB

RFC 3410, Déclarations d’introduction et d’application pour le cadre de gestion des normes Internet

RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks (Protocole de gestion de réseau simple)

Remarque :

Le RFC 3411 remplace le RFC 2571. Toutefois, Junos OS prend en charge à la fois la RFC 3411 et la RFC 2571.

RFC 3412, Traitement et distribution des messages pour le protocole SNMP (Simple Network Management Protocol)

Remarque :

Le RFC 3412 remplace le RFC 2572. Toutefois, Junos OS prend en charge à la fois la RFC 3412 et la RFC 2572.

RFC 3416, version 2 des opérations de protocole pour le protocole de gestion de réseau simple (SNMP)

Remarque :

Le RFC 3416 remplace la RFC 1905, prise en charge dans les versions antérieures de Junos OS.

RFC 3417, Mappages de transport pour le protocole SNMP (Simple Network Management Protocol)

RFC 3418, base d’informations de gestion (MIB) pour le protocole SNMP (Simple Network Management Protocol)

Remarque :

Le RFC 3418 remplace la RFC 1907, prise en charge dans les versions antérieures de Junos OS.

RFC 3584, coexistence entre la version 1, la version 2 et la version 3 de l’infrastructure de gestion du réseau selon le standard Internet

RFC 4188, Définitions des objets gérés pour les ponts

La prise en charge du système QFabric se limite aux objets suivants:

  • Dans la table dot1dBase OID, la table dot1dBasePortTable ne prend en charge que les deux premières colonnes du tableau: dot1dBasePort et dot1dBasePortIfIndex.

  • Le système n’implémente pas les pièges facultatifs qui appuient les dot1dNotifications (dot1dBridge 0).

  • Sous l’OID dot1dStp, prend en charge uniquement la table dot1dStpPortTable. Ne prend pas en charge les variables évolutives sous dot1dStp.

  • Le système ne prend pas en charge les variables évolutives dans le cadre de dot1dTp, mais sous cette base, la table dot1dTpFdbTable est prise en charge (dot1dBridge 4).

  • Dans le cas d’une solution OIDS avec prise en charge des tables uniquement, il est possible que les valeurs évolutives renvoyées par l’agent SNMP ne soient pas significatives et ne soient donc pas recommandées.

Non pris en charge sur les équipements OCX Series.

RFC 4293, base d’informations de gestion pour le protocole Internet (IP)

Prend en charge la table ipAddrTable uniquement.

Dans le système QFabric, les objets pris en charge dans la table ipAddrTable sont les suivants: ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask, ipAdEntBcastAddr et ipAdEntReasmMaxSize.

Remarque :

Sur le système QFabric, pour que la demande de mise en pratique du protocole SNMP fonctionne, vous devez configurer l’adresse IP d’au moins une interface en plus des interfaces Ethernet de gestion (me0 et me1) du groupe Director.

RFC 4363b, VLAN Q-Bridge MIB

Le système QFabric prend en charge les tableaux suivants uniquement:

  • dot1qTpFdbTable

  • dot1qVlanStaticTable

  • dot1qPortVlanTable

  • dot1qFdbTable

Non pris en charge sur les équipements OCX Series.

Remarque :

Les MBIT spécifiques à QFabric ne sont pas pris en charge sur les équipements OCX Series.

Tableau 10 : Juniper Networks MIM spécifiques à l’entreprise pris en charge sur les systèmes QFabric

MIB

Description

Analyseur MIB (mib-jnx-analyzer)

Contient des données d’analyseur et d’analyse à distance liées à la mise en miroir des ports.

Le système QFabric prend en charge:

  • Table d’analyse: jnxAnalyraname, jnxMirroringRatio, jnxLossPriority.

  • Tableau d’entrée de l’analyseur: jnxAnalysalyputValue, jnxAnalysalyputOption, jnxAnalysalysputType.

  • Tableau de sortie de l’analyseur: jnx AnalyzerOutputValue, jnxAnalysputType.

Châssis MIB (mib-jnx-chassis)

Remarque :

La MIB de châssis a été dépréciée pour le système QFabric. Nous vous recommandons d’utiliser le MIB Fabric Chassis (mib-jnx-fabric-chassis) pour obtenir des informations sur le système QFabric.

Classe de service MIB (mib-jnx-cos)

Fournit une prise en charge de la surveillance des statistiques de la file d’attente de sortie de l’interface par interface et par classe de forwarding.

Le système QFabric prend en charge les tableaux et objets suivants:

  • Jnxcosifstatflagtable— jnxCosIfstatFlags et jnxCosIfIndex.

  • Jnxcosqstattable— jnxCosQstatTxedPkts, jnxCosQstatTxedPktRate, jnxCosQstatTxedBytes et jnxCosQstatTxedByteRate.

  • Jnxcosfcidtable— jnxCosFcIdToFcName.

  • Jnxcosfctable— jnxCosFcQueueNr.

Le système QFabric ne prend en charge aucun piège pour cette MIB.

Gestion MIB de configuration (mib-jnx-cfgmgmt)

Notification des changements de configuration et des changements de configuration de sauvetage sous la forme de traps SNMP. Chaque piège contient l’heure à laquelle la modification de configuration a été commise, le nom de l’utilisateur qui a effectué la modification et la méthode par laquelle la modification a été faite.

L’historique des 32 dernières modifications de configuration est conservée dans jnxCmChgEventTable.

Remarque :

Sur le système QFabric, ces conditions s’appliquent:

  • Toutes les variables évolutives sous la table jnxCmCfgChg sont prise en charge.

  • Les OID évolutifs pris en charge sont jnxCmCfgChlatestIndex, jnxCmCfgChgLatestTime, jnxCmCfgChgLatestDate, jnxCmCfgChLatestSource, jnxCmCfgChLatestUser et jnxCmCfgChgMaxEvententries.

  • Les variables évolutives sous la table jnxCmRzueChg ne sont pas pris en charge.

Châssis MIB (mib-jnx-fabric-chassis)

Fournit des informations matérielles sur le système QFabric et ses équipements composants. Cette MIB est basée sur la Juniper Networks de châssis spécifique à l’entreprise MIB mais ajoute un autre niveau d’indexation qui fournit des informations pour les équipements des composants du système QFabric.

Interface MIB (extensions) (extensions mib-jnx-if)

Étend la norme ifTable (RFC 2863) avec des statistiques supplémentaires et Juniper Networks des informations sur les châssis spécifiques à l’entreprise dans les tables ifJnxTable et ifChassisTable.

Remarque :

Dans le système QFabric, les variables évolutives ne sont pas prise en charge.

Unité d’MIB (mib-jnx-power-supply-unit)

Assure la surveillance environnementale de l’unité d’alimentation pour l’équipement Interconnect du système QFabric.

Remarque :

Dans le système QFabric, les variables évolutives de l’ID d’objet jnxPsuObjects 1 dans la table jnxPsuScalars ne sont pas prise en charge.

QFabric MIB (jnx-qf-smi)

Explique comment les Juniper Networks MIM QFabric spécifiques à l’entreprise sont structurées. Définit les objets MIB signalés par le système QFabric et le contenu des pièges qui peuvent être publiés par le système QFabric.

Service public MIB (mib-jnx-util)

Fournit SNMP et MIB des conteneurs des types suivants: Compteurs 32 bits, compteurs 64 bits, registres signés, octet et chaînes d’octet non signées. Vous pouvez utiliser ces objets pour stocker des données qui peuvent être récupérées à l’aide d’autres opérations SNMP.

MIB objets du QFX Series

Ce sujet répertorie les Juniper Networks des objets de définition des châssis SNMP spécifiques à l’entreprise MIB pour le QFX Series:

QFX Series autonomes

Systèmes QFabric

Équipement d’QFX3100 Director système QFabric

Équipement d’QFX3008-I Interconnect système QFabric

Équipement QFabric System QFX3600-I Interconnect

Équipements de nœud du système QFabric

Châssis de MIB

L’Juniper Networks de châssis de structure SNMP spécifique à l’entreprise MIB (mib-jnx-fabric-chassis) fournit des informations matérielles sur le système QFabric et ses équipements composants en une seule MIB. Le châssis de MIB de structure est basé sur le Juniper Networks de châssis spécifique à l’entreprise MIB qui fournit des informations pour chaque équipement. Contrairement au châssis MIB, la MIB fabric chassis représente les équipements composants du système QFabric dans le système QFabric. Seules les informations du fabric chassis MIB (et non des MBIT individuelles de Chassis) sont disponibles pour les clients de gestion SNMP du système QFabric.

L’MIB Fabric Chassis utilise la structure d’informations de base du châssis MIB, mais ajoute un autre niveau d’indexation qui fournit des informations détaillées sur les équipements système QFabric. Chaque équipement physique d’un système QFabric (tel qu’un équipement de nœud ou un équipement d’interconnexion) est représenté avec ses composants matériels, y compris le alimentation, les ventilateurs et les cartes avant et arrière.

Comme dans les autres systèmes SNMP, le gestionnaire SNMP réside sur le système de gestion réseau (NMS) du réseau auquel appartient le système QFabric. L’agent SNMP (snmpd) réside dans le logiciel QFabric System Director et est chargé de recevoir et de distribuer tous les traps et de répondre à toutes les requêtes du gestionnaire SNMP. En outre, un sous-équipement SNMP s’exécute dans l moteur de routage de chaque groupe de nœuds et de chaque équipement d’interconnexion. Le sous-équipement SNMP gère les informations sur l’équipement composant et ces informations sont communiquées à l’agent SNMP dans le logiciel Director selon les besoins. Les traps générés par un équipement de nœud sont envoyés à l’agent SNMP du logiciel Director, qui les envoie ensuite aux adresses IP cibles définies dans la configuration SNMP.

Tableau 11 décrit les tableaux et objets du châssis de MIB.

Tableau 11 : Châssis de MIB tables et objets

Tableau ou nom de l’objet

Oid racine

Description

Tables avec les homologues du secteur MIB

jnxFabricContainersTable

1.3.6.1.4.1.2636.3.42.2.2.2

Fournit des informations sur différents types de conteneurs dans les équipements système QFabric.

  • Les conteneurs pour équipements d’interconnexion comprennent des plateaux de ventilateurs, des unités d’alimentation, des cartes de contrôle, etc.

  • Les conteneurs des équipements de nœuds comprennent des plateaux de ventilateurs, des unités d’alimentation, un concentrateur PIC flexible (FPC), des PIC, etc.

  • Les conteneurs des équipements Director incluent un processeur, de la mémoire, des plateaux de ventilateurs, des unités de alimentation et des disques durs. Les conteneurs ont une structure plate ou non hiérarchique, dont les composants sont organisés de manière à s’insatisaser.

jnxFabricContentsTable

1.3.6.1.4.1.2636.3.42.2.2.3

Contenu présent sur tous les équipements représentés dans l’objet jnxFabricDeviceTable. Ce tableau inclut toutes les unités remplaçables sur site (FRUS) et non frus pour les équipements système QFabric.

  • Les contenus des équipements d’interconnexion incluent des plateaux de ventilateurs et des cartes de contrôle.

  • Les contenus des équipements de nœuds incluent des plateaux de ventilateurs et des unités d’alimentation.

  • Les contenus des équipements Director incluent des processeurs, de la mémoire, des tiroirs de ventilateur, des unités d’alimentation et des disques durs, mais pas les cartes d’interface réseau (NPC).

jnxFabricFilledTable

1.3.6.1.4.1.2636.3.42.2.2.4

Affiche l’état des conteneurs dans les équipements QFabric. L’objet jnxFabricFilledState représente l’état du composant: (1) inconnu, (2) vide ou (3) rempli.

Remarque :

L’objet jnxFabricFilledTable ne contient aucune information sur le groupe Director.

jnxFabricOperatingTable

1.3.6.1.4.1.2636.3.42.2.2.5

Représente différents paramètres de fonctionnement pour le contenu de l’objet jnxFabricContentsTable.

  • Les contenus de chaque équipement de nœud et de l’équipement d’interconnexion comprennent des tiroirs de ventilateur, des unités d’alimentation, des équipements FPC, PIC et moteur de routage.

  • Les contenus de l’équipement Director comprennent des processeurs, de la mémoire, des tiroirs de ventilateur, des unités de alimentation et des disques durs, mais pas les cartes d’interface réseau (CCI).

L’objet jnxFabricOperatingState fournit l’état de l’équipement: (1) inconnu, (2) en cours d’exécution, (3) prêt, (4) réinitialisation, (5) en fonctionnementAtFullSpeed (pour ventilateurs uniquement), (6) en panne, (6) hors panne (pour les unités d’alimentation) ou (7) en veille.

jnxFabricRedundancyTable

1.3.6.1.4.1.2636.3.42.2.2.6

Représente les informations de redondance disponibles à différents niveaux de sous-système sur l’ensemble du système QFabric. Des informations sur les moteurs de routage des équipements de nœud sont incluses, mais il n’y a aucune entrée correspondante pour les équipements Interconnect dans ce tableau. La jnxFabricRedundancyL’objet indique l’état du sous-système: (1) inconnu, (2) principal, (3) sauvegarde ou (4) désactivé.

Remarque :

Pour le moment, aucune information sur les équipements Director redondants, les machines virtuelles (VM) des groupes Director Virtual Chassis périphériques virtuels n’est disponible.

jnxFabricFrutable

1.3.6.1.4.1.2636.3.42.2.2.7

Contient toutes les ERE pour le système QFabric dans la table jnxFabricDeviceTable. Les RE sont répertoriées indépendamment du fait qu’elles soient installées ou en ligne ou non. L’objet jnxFabricFruState représente l’état du FRU, notamment en ligne, hors ligne ou vide, etc. Ce tableau contient également des informations sur chaque FRU, telles que le nom, le type, la température, l’heure de dernière tension et l’heure de fin de l’alimentation.

Remarque :

Le tableau jnxFabricFruTable n’inclut pas les cartes d’interface réseau (NPC) sur les équipements Director.

Tableau spécifique au châssis de structure MIB

jnxFabricDeviceTable

1.3.6.1.4.1.2636.3.42.2.2.1

Contient des informations sur tous les équipements du système QFabric. Ce tableau organise les variables évolutives représentées dans le châssis MIB dans un format de tableau pour les équipements composants du système QFabric. Les colonnes de ce tableau incluent des informations sur l’équipement, telles que le modèle, l’alias de l’équipement et le numéro de série. Le jnxFabricDeviceIndex identifie chaque équipement système QFabric (équipement de nœud, équipement Interconnect et équipement Director).

Remarque :

Pour le moment, aucune information sur le Virtual Chassis n’est disponible.

Remarque :

Les objets suivants ne sont pas pris en charge:

  • jnxFabricDeviceEntryRevision

  • jnxFabricDeviceEntryFirmwareRevision

  • jnxFabricDeviceEntryKernelMemoryUsedPercent

Variables évolutives

Les variables évolutives suivantes sont prise en charge:

  • jnxFabricClass

  • jnxFabricDescr

  • jnxFabricSerialNo

  • jnxFabricRevision

  • jnxFabricLastinstallé

  • jnxFabricContsLastChange

  • jnxFabricFilledLastChange

1.3.6.1.4.1.2636.3.42.2.1

Décrire le système QFabric dans son ensemble.

Remarque :

La variable évolutive jnxFabricFirmwareRevision n’est pas prise en charge pour le moment.

Tableau 12 décrit les traps SNMPv2 qui sont définis dans le châssis MIB.

Remarque :

Seuls les traps SNMPv2 sont pris en charge sur le système QFabric.

Tableau 12 : Châssis de MIB traps SNMPv2

Trap Group et nom

Oid racine

Description

groupe jnxFabricChassisTraps — Comprend les traps suivants:

  • jnxFabricPowerSalyFailure

  • jnxFabric Grandefailure

  • jnxFabricOverTetature

  • jnxFabricRedundancySwitchover

  • jnxFabricFruMoval

  • jnxFabricFrusertion

  • jnxFabricFruPowerOff

  • jnxFabricFruPowerOn

  • jnxFabricFailed

  • jnxFabricFruOffline

  • jnxFabricFruOnline

  • jnxFabricFruCheck

  • jnxFabricFEBSwitchover

  • jnxFabricHardDiskFailed

  • jnxFabricHardDiskMissing

  • jnxFabricBootDebackup

  • jnxFabricHighPower

1.3.6.1.4.1.2636.4.19

Indique une condition d’alarme.

Remarque :

Les événements matériels du groupe Director sont détectés par analyse. Par conséquent, un piège ne peut pas être généré avant 30 secondes seulement après l’événement.

Remarque :

Le logiciel ne distingue pas les événements de défaillance des ventilateurs du groupe Director entre le retrait de ventilateur et les défaillances de ventilateurs. Dans chaque cas, les traps jnxFabric PuisFailure et jnxFabricFruFailed sont générés.

jnxFabricChassisOKTraps groupe — Comprend les traps suivants:

  • jnxFabricPowerSalyOK

  • jnxFabricSeok

  • jnxFabricTeaatureOK

  • jnxFabricFruOK

  • jnxFabric Haute puissance

1.3.6.1.4.1.2636.4.20

Indique une condition d’autorisation d’alarme.

Pour plus d’informations, consultez le MIB Fabric Chassis à l':

https://www.juniper.net/documentation/en_US/junos13.1/topics/reference/mibs/mib-jnx-fabric-chassis.txt

Surveillance des tables de surveillance MIB RMON

But

Surveillez les tables d’alarme, d’événements et de journaux de surveillance à distance (RMON).

Action

Pour afficher les tables RMON:

Sens

L’affichage indique qu’une alarme a été définie pour surveiller l’objet jnxRmon MIB jnxOperatingCPU, qui représente l’utilisation du processeur par le moteur de routage. L’alarme est configurée pour générer un événement qui envoie un piège SNMP et ajoute une entrée au fichier journaltable dans le fichier RMON MIB. Le tableau journal montre que deux occurrences de l’événement ont été générées: une pour augmenter au-delà d’un seuil de 90 % et une pour être inférieure à un seuil de 75 %.

Utilisation du service public spécifique à l’MIB pour améliorer la couverture SNMP

Même si le Junos OS possède des mesures de performances et des options de surveillance intégrées, vous devrez peut-être avoir des mesures de performances personnalisées. Pour vous aider à surveiller ces données personnalisées via un système de surveillance standard, le Junos OS vous fournit une MIB de service public spécifique à l’entreprise qui peut stocker de telles données et ainsi étendre la prise en charge SNMP de la gestion et de la surveillance des données de votre choix.

Le service public de l’MIB vous fournit des objets de conteneurs des types suivants: 32-bit counters, 64-bit counters et signed integersunsigned integersoctet strings . Vous pouvez utiliser ces conteneurs MIB objets pour stocker les données qui, autrement, ne sont pas prise en charge pour les opérations SNMP. Vous pouvez remplir les données de ces objets à l’aide de CLI commandes ou à l’aide de scripts Op et d’une API RPC qui peut invoquer les commandes CLI données.

Les commandes de CLI suivantes vous permettent de définir et de effacer les valeurs de MIB objet:

  • request snmp utility-mib set instance name object-type <counter | counter 64 | integer | string | unsigned integer> object-value value

  • request snmp utility-mib clear instance name object-type <counter | counter 64 | integer | string | unsigned integer>

L’option de la commande spécifie le nom de l’instance de données et constitue instance namerequest snmp utility-mib <set | clear> l’identifiant principal des données. L’option vous permet de spécifier le type d’objet, et cette option vous permet de définir object-type <counter | counter 64 | integer | string | unsigned integer>object-value value la valeur de l’objet.

Pour automatiser le processus de MIB des données utility, vous pouvez utiliser une combinaison de stratégie d’événements et de scripts d’événements. Les exemples suivants indiquent la configuration d’une stratégie d’événements qui doit être exécuté toutes les heures et qui permet de stocker les données dans les objets Utility MIB en exécutant un show system buffers script d’événements show system bufferscheck-mbufs.slax ().

Configuration de la stratégie d’événement

Pour configurer une stratégie d’événements qui exécute la commande toutes les heures et qui les appelle pour stocker les données dans des objets Utility MIB, incluent les instructions suivantes au niveau show system bufferscheck-mbufs.slax [ ] show system buffersedit hiérarchique:

script check-mbufs.slax

L’exemple suivant affiche le check-mbufs.slax script stocké /var/db/scripts/event/ sous:

Vous pouvez exécuter la commande suivante pour vérifier les données stockées dans le MIB de service public à la suite de la stratégie d’événement et du script illustrés dans les exemples précédents:

Remarque :

La commande n’est pas disponible sur le système QFabric, mais vous pouvez utiliser des applications client SNMP externes show snmp mib walk pour réaliser cette opération.

Exemple: Configuration de SNMP

Par défaut, le SNMP est désactivé sur les équipements qui s’exécutent Junos OS. Cet exemple décrit les étapes de configuration de SNMP sur le système QFabric.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants:

  • Junos OS version 12.2

  • Système de gestion du réseau (NMS) (exécutant le gestionnaire SNMP)

  • Système QFabric (exécutant l’agent SNMP) avec plusieurs équipements de nœuds

Présentation

Étant donné que SNMP est désactivé par défaut sur les équipements qui s’exécutent Junos OS, vous devez activer le SNMP sur votre équipement en incluant les instructions de configuration au niveau [edit snmp] de la hiérarchie. Au minimum, vous devez configurer community public l’énoncé. La communauté définie comme étant une aide publique permet un accès en lecture seule MIB données à n’importe quel client.

Si aucune clients instruction n’est configurée, tous les clients sont autorisés. Il est recommandé de toujours inclure la possibilité de limiter l’accès restrict client SNMP au commutateur.

Topologie

La topologie réseau de cet exemple comprend un système NMS, un système QFabric comprenant quatre équipements de nœuds et des serveurs SNMP externes configurés pour les traps de réception.

Configuration

Procédure

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, puis copiez/collez les commandes dans le CLI au niveau de la [edit] hiérarchie.

Procédure étape par étape

L’exemple suivant nécessite de naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer SNMP sur le système QFabric:

Remarque :

Si le nom, la description, le lieu, le contact ou le nom de la communauté contient des espaces, joint le texte dans des guillemets ( » « ).

  1. Configurer le nom du système SNMP:

    Remarque :

    Vous pouvez accéder au nom du système SNMP configuré ci-dessus:

    • En interrogeant SNMPGet sur le policy object identifier (OID) sysName.0.

    • Du jnxSyslogTrap générique. Pour envoyer la jnxSyslogTrap, configurez les événements de trap à [edit event-options policy] la hiérarchie.

  2. Indiquez une description.

    Cette chaîne est placée dans l’objet MIB II de sysDescription.

  3. Indiquez l’emplacement physique du système QFabric.

    Cette chaîne est placée dans l’MIB SysLocation II.

  4. Indiquez un contact administratif pour le système SNMP.

    Ce nom est placé dans l MIB II sysContact.

  5. Indiquez un nom de communauté SNMP unique et un niveau d’autorisation en lecture seule.

    Remarque :

    Cette read-write option n’est pas prise en charge par le système QFabric.

  6. Créez une liste de clients avec un ensemble d’adresses IP qui peuvent utiliser la communauté SNMP.

  7. Indiquez les adresses IP des clients limités de l’utilisation de la communauté.

  8. Configurez un groupe de traps, un port de destination et une cible pour recevoir les traps SNMP dans le groupe de traps.

    Remarque :

    Il n’est pas nécessaire d’inclure destination-port l’instruction si vous utilisez le port 162 par défaut.

    Les traps du groupe de traps qf-traps sont configurés pour envoyer des traps vers 192.168.0.100.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant la show commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Configuration des alarmes et des événements RMON

La Junos OS prend en charge la MIB de surveillance de réseau distant (RMON) (RFC 2819), qui permet à un dispositif de gestion de surveiller les valeurs d’objets ou de variables MIB à l’aide de seuils configurés. Lorsque la valeur d’une variable atteint un seuil, une alarme et son événement correspondant sont générés. L’événement peut être enregistré et générer un piège SNMP.

Pour configurer les alarmes et les événements RMON à l’CLI, exécutez ces tâches:

Configuration de SNMP

Pour configurer SNMP:

  1. Grant accès en lecture seule à tous les clients SNMP:

    Quelques chiffres clés :

  2. Accès par lecture-écriture Grant aux MIM RMON et jnx-rmon:

    Quelques chiffres clés :

    Les ONID 1.3.6.1.2.1.16 et 1.3.6.1.1.1.2636.13 correspondent aux MIM RMON et jnxRmon.

  3. Configurer un groupe de traps SNMP:

    Quelques chiffres clés :

    Le groupe de traps rmon-trap est configuré pour envoyer des traps RMON au 192.168.5.5.

Configuration d’un événement

Pour configurer un événement:

  1. Configurer un index d’événement, un nom de communauté et le type:

    Quelques chiffres clés :

    La communauté d’événements correspond au groupe de trap SNMP et n’est pas la même que celle d’une communauté SNMP. Cet événement génère un piège SNMP et ajoute une entrée au fichier journaltable dans l’MIB RMON.

  2. Configurez une description de l’événement:

    Quelques chiffres clés :

Configuration d’une alarme

Pour configurer une alarme:

  1. Configurez un index d’alarme, la variable à surveiller, l’augmentation et la baisse des seuils, ainsi que les événements correspondants:

    Quelques chiffres clés :

    La variable .1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0 correspond à l’objet jnxRmon MIB jnxOperatingCPU, qui représente l’utilisation du processeur de l’moteur de routage. Les nombres d’tegs en cours de chute et d’augmentation sont de 75 ou 90. La hausse et la chute des événements génèrent tous deux le même événement (index d’événements 1).

  2. Configurez l’intervalle, le type d’échantillon et le type d’alarme:

    Quelques chiffres clés :

    La valeur absolue de la variable surveillé est échantillonée toutes les 30 secondes. L’alarme initiale peut se produire en raison d’une hausse ou d’un d’un seuil inférieur à ce seuil.