Configurer SNMP pour les instances de routage

Junos OS permet aux gestionnaires SNMP de toutes les instances de routage de demander et de gérer les données SNMP relatives aux instances de routage et aux réseaux de systèmes logiques correspondants.

Dans Junos OS :

• Les clients provenant d’instances de routage et/ou de systèmes logiques autres que le système par défaut peuvent accéder aux objets MIB et effectuer des opérations SNMP uniquement sur les réseaux d’instance de routage et/ou de système logique auxquels ils appartiennent.

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

• L’instance de routage de gestion Junos (mgmt_junos) est une instance spéciale. Les clients de l’instance de routage de gestion sont traités comme s’ils se trouvaient dans l’instance de routage par défaut et peuvent accéder aux informations relatives à toutes les instances de routage et aux réseaux du système logique.

Avec l’augmentation des offres de services de réseau privé virtuel (VPN), cette fonctionnalité est particulièrement utile pour les fournisseurs de services qui ont besoin d’obtenir des données SNMP pour des instances de routage spécifiques (voir Figure 1). Les fournisseurs de services peuvent utiliser ces informations pour leurs propres besoins de gestion ou exporter les données pour les utiliser par leurs clients.

Figure 1 : Données SNMP pour les instances de routage

Si aucune instance de routage n’est spécifiée dans la requête, l’agent SNMP fonctionne comme avant :

• Pour les objets de table non routage, toutes les instances sont exposées.

• Pour les objets de table de routage, seuls ceux associés à l’instance de routage par défaut sont exposés.

  Remarque :

  Les unités de données de protocole (PDU) réelles sont toujours échangées sur l’instance de routage par défaut (inet.0), mais le contenu des données renvoyé est dicté par l’instance de routage spécifiée dans les PDU de demande.

Vous pouvez accéder aux informations relatives à toutes les instances de routage et réseaux de systèmes logiques et non spécifiques aux instances de routage entrantes en configurant l’interface de gestion SNMPv3 dans une instance de routage requise. Vous pouvez configurer l’instruction de configuration de l’instance de gestion au niveau de la [edit snmp v3] hiérarchie.

• Avantages
• Activer l’instance de routage de gestion
• Supprimer l’instance de routage de gestion

Le Tableau 1 présente les objets MIB spécifiques à l’entreprise pris en charge par Junos OS et fournit des notes détaillées sur la façon dont ils sont gérés lorsqu’une instance de routage est spécifiée dans une requête SNMP. Un tiret (–) indique que l’article ne s’applique pas.

Le Tableau 2 présente les objets MIB de Classe 1 (MIB standard et spécifiques à l’entreprise) pris en charge par Junos OS. Avec les objets de classe 1, seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées.

Le Tableau 3 présente les objets MIB de classe 2 (MIB standard et spécifiques à l’entreprise) pris en charge par Junos OS. Avec les objets de classe 2, toutes les instances d’un système logique sont exposées. Les données ne seront pas séparées jusqu’au niveau de l’instance de routage.

Le Tableau 4 présente les objets MIB de classe 3 (MIB standard et spécifiques à l’entreprise) pris en charge par Junos OS. Avec la classe 3, les objets sont exposés uniquement pour le système logique par défaut.

Le Tableau 5 présente les objets MIB de classe 4 (MIB standard et spécifiques à l’entreprise) pris en charge par Junos OS. Avec les objets de classe 4, les données ne sont pas séparées par instance de routage. Toutes les instances sont exposées.

Lorsqu’une instance de routage est spécifiée, tous les objets MIB liés au routage renvoient les données gérées par l’instance de routage dans la demande. Pour tous les autres objets MIB, les données renvoyées sont séparées en fonction de cette instance de routage. Par exemple, seules les interfaces affectées à cette instance de routage (par exemple, les interfaces logiques [ifls] ainsi que leurs interfaces physiques correspondantes [ifds]) sont exposées par l’agent SNMP. De même, les objets ayant un attachement non ambigu à une interface (par exemple, des adresses) sont également séparés.

Pour les objets dont la pièce jointe est ambiguë (par exemple, les objets dans sysApplMIB), aucune ségrégation n’est effectuée et toutes les instances sont visibles dans tous les cas.

Une autre catégorie d’objets n’est visible que lorsqu’aucun système logique n’est spécifié (uniquement dans le système logique par défaut), quelle que soit l’instance de routage dans le système logique par défaut. Les objets de cette catégorie sont les objets MIB de châssis, les objets du groupe SNMP, les groupes d’alarmes RMON, d’événements et de journaux, les objets Ping MIB, les objets de gestion de la configuration et les objets V3.

En résumé, pour prendre en charge les instances de routage, les objets MIB appartiennent à l’une des catégories suivantes :

• Classe 1 : les données sont séparées en fonction de l’instance de routage dans la demande. Il s’agit de la plus granulaire des classes de ségrégation.

• Classe 2 : les données sont séparées selon le système logique spécifié dans la demande. Les mêmes données sont renvoyées pour toutes les instances de routage appartenant à un système logique particulier. En règle générale, cela s’applique aux objets de la table de routage pour lesquels il est difficile d’extraire les informations de l’instance de routage ou pour lesquels les instances de routage ne s’appliquent pas.

• Classe 3 : les données sont exposées uniquement pour le système logique par défaut. Le même ensemble de données est renvoyé pour toutes les instances de routage qui appartiennent au système logique par défaut. Si vous spécifiez un autre système logique (autre que le système par défaut), aucune donnée n’est renvoyée. En règle générale, cette classe s’applique aux objets implémentés dans les sous-agents qui ne surveillent pas les modifications du système logique et enregistrent leurs objets en utilisant uniquement le contexte par défaut (par exemple, les objets MIB Chassis).

• Classe 4 : les données ne sont pas séparées par instance de routage. Les mêmes données sont renvoyées pour toutes les instances de routage. En règle générale, cela s’applique aux objets implémentés dans les sous-agents qui surveillent les modifications du système logique et enregistrent ou annulent l’enregistrement de tous leurs objets pour chaque modification du système logique. Les objets dont les valeurs ne peuvent pas être séparées par instance de routage entrent dans cette classe.

Voir MIB SNMP prises en charge pour les instances de routage pour obtenir la liste des objets associés à chaque classe.

Vous pouvez empêcher les récepteurs d’interruption de recevoir des interruptions qui ne sont pas liées aux réseaux du système logique auxquels elles appartiennent. Pour ce faire, incluez l’instruction logical-system-trap-filter au niveau de la [edit snmp] hiérarchie :

Si l’instruction n’est logical-system-trap-filter pas incluse dans la configuration SNMP, toutes les interruptions sont transférées vers les destinations d’instance de routage configurées. Toutefois, même lorsque cette instruction est configurée, le récepteur d’interruption associé à l’instance de routage par défaut recevra toutes les interruptions SNMP.

Lorsqu’elles sont configurées sous l’objet trap-group, toutes les interruptions v1 et v2c qui s’appliquent aux instances de routage (ou aux interfaces appartenant à une instance de routage) ont le nom de l’instance de routage codé dans la chaîne de communauté. L’encodage est identique à celui utilisé dans les PDU de requête.

Pour les interruptions configurées dans le cadre v3, le nom de l’instance de routage est porté dans le champ contextuel lorsque le modèle de traitement des messages v3 a été configuré. Pour les autres modèles de traitement de message (v1 ou v2c), le nom de l’instance de routage n’est pas porté dans l’en-tête du message d’interruption (et n’est pas codé dans la chaîne de communauté).

Avec cette fonctionnalité, les instances de routage sont identifiées par le champ de contexte dans les requêtes v3 ou encodées dans la chaîne de communauté dans les requêtes v1 ou v2c.

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

Pour éviter les conflits avec les chaînes de communauté valides qui contiennent le @ caractère, la communauté est analysée uniquement si le traitement typique de la chaîne de communauté échoue. Par exemple, si une instance de routage nommée RI est configurée, une requête SNMP avec RI@public est traitée dans le contexte de l’instance RI de routage. Le contrôle d’accès (vues, restrictions d’adresse source, privilèges d’accès, etc.) est appliqué en fonction de la chaîne de communauté réelle (l’ensemble de données après le @ caractère, dans ce cas public). Toutefois, si la chaîne RI@public de communauté est configurée, l’unité de données de protocole (PDU) est traitée en fonction de cette communauté et le nom de l’instance de routage incorporée est ignoré.

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

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

Cet exemple montre une configuration d’interface 802.3ad ae0 allouée à une instance de routage nommée INFrtd :

La commande suivante snmpwalk montre comment récupérer des informations relatives au SNMP à partir du routeur1 et de l’interface de bundle 802.3ae appartenant à l’instance de routage INFrtd avec la communauté publicSNMP :

Cet exemple montre la configuration d’une instance InBandManagement de routage pour une communauté myCommunity1.

L’instance de routage est limitée à une interface et-0/0/16. Les clients restreints sont configurés comme SNMPClients dans les options de stratégie.

La commande suivante snmpwalk montre comment envoyer une requête SNMP du client configuré à l’interface et-0/0/16 en tant que routinginstance@community: