Sur cette page
Comprendre la prise en charge de SNMP pour les instances de routage
Interruptions SNMP prises en charge pour les instances de routage
Spécification d’une instance de routage dans une communauté SNMPv1 ou SNMPv2c
Exemple : Configurer les paramètres d’interface d’une instance de routage
Configurer les listes d’accès pour l’accès SNMP sur les instances de routage
Configurer SNMP pour les instances de routage
Comprendre la prise en charge de 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 associées aux instances de routage et aux réseaux de systèmes logiques correspondants.
Dans Junos OS :
Les clients des instances de routage et/ou des systèmes logiques autres que celui par défaut peuvent accéder aux objets MIB et effectuer des opérations SNMP uniquement sur l’instance de routage et/ou les réseaux de systèmes logiques 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 à tous les réseaux de systèmes logiques.
Avant Junos OS version 8.4, seul le gestionnaire SNMP de l’instance de routage par défaut (inet.0) avait accès aux objets MIB.
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 (reportez-vous à la section 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.
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 qui ne sont pas de 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 via l’instance de routage par défaut (inet.0), mais le contenu des données renvoyées est dicté par l’instance de routage spécifiée dans les PDU de demande.
Instance de routage de gestion SNMPv3
À partir de Junos OS 19.4R1, vous pouvez accéder aux informations relatives à toutes les instances de routage et aux réseaux de systèmes logiques, et non spécifiques à l’instance de routage entrante, 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
L’instance de routage de gestion SNMPv3 active toutes les requêtes SNMPv3 provenant d’une instance de routage autre que celle par défaut, comme si les requêtes provenaient d’une instance de routage par défaut. À l’aide de l’instance de routage de gestion SNMPv3, vous accédez aux informations relatives à toutes les instances de routage et aux réseaux de systèmes logiques.
Activer l’instance de routage de gestion
Pour activer l’instance de routage de gestion SNMPv3 :
Configurez l’instruction management-instance.
[edit]
user@host#set snmp v3 management-routing-instance <routing-instance>
Validez la configuration.
[edit]
user@host#commit
Supprimer l’instance de routage de gestion
Pour supprimer l’instance de routage de gestion SNMPv3 :
Supprimez ou désactivez l’instruction d’instance de routage de gestion SNMPv3.
[edit]
user@host#delete snmp v3 management-routing-instance <routing-instance>
Vous ne pouvez pas configurer l’instance de routage de gestion Junos (mgmt_junos
) au niveau de la hiérarchie [edit snmp v3 management-routing-instance <routing-instance>
], car le mgmt_junos
a accès à toutes les instances de routage par défaut.
MIB SNMP prises en charge pour les instances de routage
Tableau 1 affiche les objets MIB spécifiques à l’entreprise pris en charge par Junos OS et fournit des notes détaillant leur gestion lorsqu’une instance de routage est spécifiée dans une requête SNMP. Un tiret cadratin (–) indique que l’élément ne s’applique pas.
Objet |
Classe de soutien |
Description/Notes |
---|---|---|
jnxProduits(1) |
– |
ID d’objets produit |
jnxServices(2) |
– |
Services |
jnxMibs(3) jnxBoxAnatomie(1) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
MPLS(2) |
Classe 2 |
Toutes les instances d’un système logique sont exposées. Les données ne seront pas séparées au niveau de l’instance de routage. |
ifJnx(3) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxAlarmes(4) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxPare-feu(5) |
Classe 4 |
Les données ne sont pas séparées par instance de routage. Toutes les instances sont exposées. |
jnxDCU(6) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxPingMIB(7) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxTraceRouteMIB(8) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxATM(10) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxIpv6(11) |
Classe 4 |
Les données ne sont pas séparées par instance de routage. Toutes les instances sont exposées. |
jnxIpv4(12) |
Classe 1 |
jnxIpv4AddrTable(1). Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxRmon(13) |
Classe 3 |
jnxRmonAlarmTable(1). Les objets ne sont exposés que pour le système logique par défaut. |
jnxLdp(14) |
Classe 2 |
jnxLdpTrapVars(1). Toutes les instances d’un système logique sont exposées. Les données ne seront pas séparées au niveau de l’instance de routage. |
jnxCos(15) jnxCosIfqStatsTable(1) jnxCosFcTable(2) jnxCosFcIdTable(3) jnxCosQstatTable(4) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxScu(16) jnxScuStatsTable(1) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxRpf(17) jnxRpfStatsTable(1) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxCfgMgmt(18) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxPMon(19) jnxPMonFlowTable(1) jnxPMonErrorTable(2) jnxPMonMemoryTable(3) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxSonet(20) jnxSonetAlarmTable(1) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxAtmCos(21) jnxCosAtmVcTable(1) jnxCosAtmScTable(2) jnxCosAtmVcQstatsTable(3) jnxCosAtmTrunkTable(4) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
ipSecFlowMonitorMIB(22) |
– |
– |
jnxMac(23) jnxMacStats(1) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
apsMIB(24) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxChassisDéfinit(25) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
jnxVpnMIB(26) |
Classe 2 |
Toutes les instances d’un système logique sont exposées. Les données ne seront pas séparées au niveau de l’instance de routage. |
jnxSericesInfoMib(27) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxCollectorMIB(28) |
Classe 1 |
Seules les interfaces logiques (et leurs interfaces physiques parentes) qui appartiennent à une instance de routage spécifique sont exposées. |
jnxHistoire(29) |
– |
– |
jnxSpMIB(32) |
Classe 3 |
Les objets ne sont exposés que pour le système logique par défaut. |
Tableau 2 affiche 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.
Classe |
MIB |
Objets |
---|---|---|
Classe 1 |
802.3ad.mib |
(dot3adAgg) Objets MIB : dot3adAggTable dot3adAggPortListTable (dot3adAggPort) dot3adAggPortTable dot3adAggPortStatsTable dot3adAggPortDebugTable |
rfc2863a.mib |
ifTable ifXTable ifStackTable |
|
rfc2011a.mib |
ipAddrTable ipNetToMediaTable |
|
rtmib.mib |
ipForward (ipCidrRouteTable) |
|
rfc2665a.mib |
dot3StatsTable dot3ControlTable dot3PauseTable |
|
rfc2495a.mib |
dsx1ConfigTable dsx1CurrentTable dsx1IntervalTable dsx1TotalTable dsx1FarEndCurrentTable dsx1FarEndIntervalTable dsx1FarEndTotalTable dsx1FracTable ... |
|
rfc2496a.mib |
dsx3 (dsx3ConfigTable) |
|
rfc2115a.mib |
frDlcmiTable (et les objets MIB associés) |
|
rfc3592.mib |
sonetMediumTable (et les objets MIB associés) |
|
rfc3020.mib |
mfrMIB mfrBundleTable mfrMibBundleLinkObjects mfrBundleIfIndexMappingTable (et les objets MIB associés) |
|
ospf2mib.mib |
Tous les objets |
|
ospf2trap.mib |
Tous les objets |
|
bgpmib.mib |
Tous les objets |
|
rfc2819a.mib |
Exemple : etherStatsTable |
|
Classe 1 |
rfc2863a.mib |
Exemples: ifXtable ifStackTable |
rfc2665a.mib |
etherMIB |
|
rfc2515a.mib |
objets atmMIB Exemples: atmInterfaceConfTable atmVplTable atmVclTable |
|
rfc2465.mib |
IP-V6MIB Exemples: ipv6IfTable ipv6AddrPrefixTable ipv6NetToMediaTable ipv6RouteTable |
|
rfc2787a.mib |
MIB VRRP |
|
rfc2932.mib |
ipMRouteMIB ipMRouteStdMIB |
|
mroutemib.mib |
ipMRoute1MIBObjects |
|
isismib.mib |
isisMIB |
|
pimmib.mib |
pimMIB |
|
msdpmib.mib |
MSDPMIB (en anglais seulement) |
|
jnx-if-extensions.mib |
Exemples: ifJnxTable ifChassisTable |
|
jnx-dcu.mib |
Les JNXDCU |
|
jnx-atm.mib |
Exemples: jnxAtmIfTable jnxAtmVCTable jnxAtmVpTable |
|
jnx-ipv4.mib |
jnxipv4 Exemple : jnxIpv4AddrTable |
|
jnx-cos.mib |
Exemples: jnxCosIfqStatsTable jnxCosQstatTable |
|
jnx-scu.mib |
Exemple : jnxScuStatsTable |
|
jnx-rpf.mib |
Exemple : jnxRpfStatsTable |
|
jnx-pmon.mib |
Exemple : jnxPMonFlowTable |
|
jnx-sonet.mib |
Exemple : jnxSonetAlarmTable |
|
Classe 1 |
jnx-atm-cos.mib |
Exemples: jnxCosAtmVcTable jnxCosAtmVcScTable jnxCosAtmVcQstatsTable jnxCosAtmTrunkTable |
jnx-mac.mib |
Exemple : jnxMacStatsTable |
|
jnx-services.mib |
Exemple : jnxSvcFlowTableAggStatsTable |
|
coll.mib jnx-coll.mib |
jnxCollectorMIB Exemples: jnxCollPicIfTable jnxCollFileEntry |
Tableau 3 affiche 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 au niveau de l’instance de routage.
Classe |
MIB |
Objets |
---|---|---|
Classe 2 |
rfc3813.mib |
mplsLsrStdMIB Exemples: mplsInterfaceTable mplsInSegmentTable mplsOutSegmentTable mplsLabelStackTable mplsXCTable (et les objets MIB associés) |
igmpmib.mib |
igmpStdMIB REMARQUE :
Il |
|
l3vpnmib.mib |
mplsVpnmib |
|
jnx-mpls.mib |
Exemple : mplsLspList |
|
jnx-ldp.mib |
jnxLdp Exemple : jnxLdpStatsTable |
|
jnx-vpn.mib |
jnxVpnMIB |
|
jnx-bgpmib2.mib |
jnxBgpM2Expérience |
Tableau 4 affiche 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 ne sont exposés que pour le système logique par défaut.
Classe |
MIB |
Objets |
---|---|---|
Classe 3 |
rfc2819a.mib |
rmonEvents table d’alarme logTable eventTable agentxMIB |
rfc2925a.mib |
pingmib |
|
rfc2925b.mib |
tracerouteMIB |
|
jnxchassis.mib |
jnxBoxAnatomie |
|
alarme-châssis.mib |
alarmes jnx Par défaut, les pare-feu SRX Series interrogent la mib jnxAlarms uniquement sur le nud principal du groupe de redondance 0 (RG0) et non sur le nud secondaire. |
|
jnx-ping.mib |
jnxPingMIB |
|
jnx-traceroute.mib |
jnxTraceRouteMIB |
|
jnx-rmon.mib |
jnxRmonAlarmTable |
|
jnx-cos.mib |
Exemple : jnxCosFcTable |
|
jnx-cfgmgmt.mib |
Exemple : jnxCfgMgmt |
|
jnx-sonetaps.mib |
apsMIBObjects |
|
jnx-sp.mib |
jnxSpMIB |
|
ggsn.mib |
ejnmobileipABmib |
|
rfc1907.mib |
Modules snmp |
|
Modules snmp |
Exemples: snmpMIB snmpFrameworkMIB |
Tableau 5 affiche 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.
Classe |
MIB |
Objets |
---|---|---|
Classe 4 |
Système |
Exemple : sysORTable |
rfc2011a.mib |
ip (ipDefaultTTL, ipInReceives) Icmp |
|
rfc2012a.mib |
Tcp tcpConnTable ipv6TcpConnTable |
|
rfc2013a.mib |
Udp udpTable ipv6UdpTable |
|
rfc2790a.mib |
hrSystem |
|
rfc2287a.mib |
sysApplOBJ |
|
pare-feu.mib |
Pare-feu jnx |
|
jnx-ipv6.mib |
jnxIpv6 |
Classes de support pour les objets MIB
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 l’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 avec une attache non ambiguë à une interface (par exemple, les 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 châssis, les objets du groupe SNMP, les groupes d’alarmes, d’événements et de journaux RMON, les objets MIB ping, 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 en fonction du 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 table de routage où il est difficile d’extraire les informations de l’instance de routage ou lorsque 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 appartenant 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 des sous-agents qui ne surveillent pas les modifications apportées au système logique et enregistrent leurs objets en utilisant uniquement le contexte par défaut (par exemple, les objets MIB du châssis).
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 des 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 appartiennent à cette classe.
Reportez-vous à la section MIB SNMP prises en charge pour les instances de routage pour obtenir la liste des objets associés à chaque classe.
Interruptions SNMP prises en charge pour les instances de routage
Vous pouvez empêcher les récepteurs d’interruptions de recevoir des interruptions qui ne sont pas liées aux réseaux de systèmes logiques auxquels ils appartiennent. Pour ce faire, incluez l’instruction logical-system-trap-filter
au niveau de la [edit snmp]
hiérarchie :
[edit snmp] logical-system-trap-filter;
Si l’instruction n’est pas incluse dans la configuration SNMP, toutes les interruptions sont transmises aux destinations de l’instance logical-system-trap-filter
de routage configurées. Toutefois, même lorsque cette instruction est configurée, le récepteur d’interruptions associé à l’instance de routage par défaut reçoit toutes les interruptions SNMP.
Lorsqu’ils sont configurés sous l’objet trap-group, tous 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 encodé dans la chaîne de communauté. L’encodage est identique à celui utilisé dans les PDU de requête.
Pour les interruptions configurées sous l’infrastructure v3, le nom de l’instance de routage est porté dans le champ de contexte lorsque le modèle de traitement des messages v3 a été configuré. Pour les autres modèles de traitement des messages (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 encodé dans la chaîne de communauté).
Identification d’une instance de routage
Avec cette fonctionnalité, les instances de routage sont identifiées soit par le champ de contexte dans les requêtes v3, soit encodées dans la chaîne de communauté dans les requêtes v1 ou v2c.
Lorsqu’il est encodé 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 des chaînes de communauté valides qui contiennent le caractère, la communauté n’est analysée que si le @
traitement de chaîne de communauté typique é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 exécutent un sous-ensemble des actions d’un routeur physique et possèdent leurs propres tables de routage, interfaces, stratégies et instances de routage. Lorsqu’une instance de routage est définie au sein d’un système logique, le nom du système logique doit être encodé en même temps que l’instance de routage à l’aide d’une barre oblique ( /
) pour séparer les deux. Par exemple, si l’instance de routage est configurée dans le système LS
logique , cette instance RI
de routage doit être codée dans une chaîne de communauté sous la forme 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.
De plus, 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 .
Pour identifier une instance Virtual LAN (VLAN) spanning-tree (VSTP sur les plates-formes de routage universelles 5G MX Series), spécifiez le nom de l’instance de routage suivi d’un double deux-points (::
) et de l’ID de VLAN. Par exemple, pour identifier l’instance VSTP pour le VLAN 10 dans l’instance de routage globale par défaut, incluez default::10@public
la context
chaîne (SNMPv3) ou (SNMPv1 ou community
v2).
Activer l’accès SNMP sur les instances de routage
Pour permettre aux gestionnaires SNMP d’instances de routage autres que l’instance de routage par défaut d’accéder aux informations SNMP, incluez l’instruction routing-instance-access
au niveau de la [edit snmp]
hiérarchie.
Si cette instruction n’est pas incluse dans la configuration SNMP, les responsables SNMP des instances de routage autres que l’instance de routage par défaut ne peuvent pas accéder aux informations SNMP. Ce paramètre s’applique aux requêtes pour n’importe quelle version de SNMP (SNMP v1, v2 ou v3).
Spécification d’une instance de routage dans une communauté SNMPv1 ou SNMPv2c
Vous pouvez spécifier l’instance de routage ainsi que les informations du client lorsque vous ajoutez un client à une communauté SNMP. Pour spécifier l’instance de routage à laquelle appartient un client, incluez l’instruction suivie du nom de l’instance routing-instance
de routage et des informations sur le client dans la configuration SNMP.
L’exemple suivant montre l’instruction de configuration permettant d’ajouter l’instance de routage test-ri à la communauté SNMP1.
Les instances de routage spécifiées au niveau de la hiérarchie sont ajoutées au système logique par défaut de la [edit snmp community community-name]
communauté.
[edit snmp] community community1 { clients { 10.209.152.33/32; } routing-instance test-ri { clients { 10.19.19.1/32; } } }
Si l’instance de routage est définie au sein d’un système logique, incluez l’instruction au niveau de la hiérarchie [edit snmp community community-name logical-system logical-system-name
], comme dans l’exemple routing-instance
suivant :
[edit snmp] community community1 { clients { 10.209.152.33/32; } logical-system test-LS { routing-instance test-ri { clients { 10.19.19.1/32; } } } }
Exemple : Configurer les paramètres d’interface d’une instance de routage
Cet exemple montre une configuration d’interface 802.3ad ae0 allouée à une instance de routage nommée INFrtd :
[edit chassis] aggregated-devices { ethernet { device-count 5; } } [edit interfaces ae0] vlan-tagging; aggregated-ether-options { minimum-links 2; link-speed 100m; } unit 0 { vlan-id 100; family inet { address 10.1.0.1/24; } } [edit interfaces fe-1/1/0] fastether-options { 802.3ad ae0; } [edit interfaces fe-1/1/1] fastether-options { 802.3ad ae0; } [edit routing-instances] INFrtd { instance-type virtual-router; interface fe-1/1/0.0; interface fe-1/1/1.0; interface fe-1/1/5.0; interface ae0.0; protocols { ospf { area 0.0.0.0 { interface all; } } } }
La commande suivante snmpwalk
montre comment récupérer les informations relatives à SNMP à partir du routeur1 et de l’interface de bundle 802.3ae appartenant à l’instance de routage INFrtd avec la communauté public
SNMP :
router# snmpwalk -Os router1 INFrtd@public dot3adAggTable dot3adAggMACAddress.59 = 0:90:69:92:93:f0 dot3adAggMACAddress.65 = 0:90:69:92:93:f0 dot3adAggActorSystemPriority.59 = 0 dot3adAggActorSystemPriority.65 = 0 dot3adAggActorSystemID.59 = 0:0:0:0:0:0 dot3adAggActorSystemID.65 = 0:0:0:0:0:0 dot3adAggAggregateOrIndividual.59 = true(1) dot3adAggAggregateOrIndividual.65 = true(1) dot3adAggActorAdminKey.59 = 0 dot3adAggActorAdminKey.65 = 0 dot3adAggActorOperKey.59 = 0 dot3adAggActorOperKey.65 = 0 dot3adAggPartnerSystemID.59 = 0:0:0:0:0:0 dot3adAggPartnerSystemID.65 = 0:0:0:0:0:0 dot3adAggPartnerSystemPriority.59 = 0 dot3adAggPartnerSystemPriority.65 = 0 dot3adAggPartnerOperKey.59 = 0 dot3adAggPartnerOperKey.65 = 0 dot3adAggCollectorMaxDelay.59 = 0 dot3adAggCollectorMaxDelay.65 = 0
Configurer les listes d’accès pour l’accès SNMP sur les instances de routage
Vous pouvez créer et gérer des listes d’accès pour gérer l’accès aux informations SNMP. La configuration de la liste d’accès vous permet d’autoriser ou de refuser l’accès SNMP aux clients d’une instance de routage spécifique et s’applique aux demandes de n’importe quelle version de SNMP.
L’exemple suivant montre comment créer une liste d’accès :
[edit snmp] routing-instance-access { access-list { ri1 restrict; ls1/default; ls1/ri2; ls1*; } }
La configuration donnée dans l’exemple :
Empêche les clients d’accéder aux
ri1
informations SNMP.Permet aux clients de ,
ls1/ri2
et de toutes les autres instances de routage dont le nom commence parls1
d’accéder auxls1/default
informations SNMP.
Vous pouvez utiliser le caractère générique (*) pour représenter une chaîne dans le nom de l’instance de routage.
Vous ne pouvez pas empêcher le gestionnaire SNMP de l’instance de routage par défaut d’accéder aux informations SNMP.