Contenu

Présentation de la notification de déroutement SNMP :

Conditions préalables

Architecture de gestion des pannes SNMP :

Configuration SNMP dans un environnement multi-étagère :

Configuration SNMP sur le proxy Socks d'environnement multi-étagère :

MIB propriétaires :

Fichiers MIB SMIv1/SMIv2 pour Cisco ONS 15454 :

Chargement des fichiers MIB dans les plates-formes NMS :

Chargement MIB dans le gestionnaire de noeuds réseau HPOV

Table de dépendances MIB :

Gestion des déroutements :

Exemple de déroutements SNMP V1 :

Le déroutement est-il une alarme ServiceAffecting ?

Exemple de déroutements SNMP V2 :

Même procédure :

Documentation pertinente :

Discussions connexes de la communauté d’assistance Cisco

Présentation de la notification de déroutement SNMP :

Un déroutement SNMP est essentiellement un ensemble de notifications asynchrones d'un agent SNMP à un système de gestion de réseau. Comme les autres messages du protocole SNMP, les déroutements sont envoyés à l’aide du protocole UDP.

Un déroutement est un ensemble de données défini par une base d'informations gérée (MIB). Les pièges sont classés en catégories : Générique et spécifique à l'entreprise.

Conditions préalables

- Connaissances SNMP de base.

- Présentation du MSTP Cisco 15454.

Architecture de gestion des pannes SNMP::

Configuration SNMP dans un environnement multi-étagère :

- Lorsqu'un noeud Multi-Shelter est connecté uniquement à OSC (ou GCC), il envoie les déroutements au LAN de toute façon.

- Pour éviter ce problème, le noeud de passerelle, c'est-à-dire le noeud connecté au réseau local, doit être défini comme suit :

- ” proxy uniquement “

- Ou GNE.

- Ci-dessous, une description du Proxy Socks :

Proxy Socks (GNE, ENE, Proxy uniquement, LNE)

Si le bouton Activer le proxy Socks est sélectionné.  Et GNE est sélectionné.

— Crée un tunnel SOCKS à construire entre le PC exécutant CTC et le noeud connecté au réseau local.

— Cela signifie que c'est le noeud de passerelle (GNE) qui utilise SOCKS PROXY.

— Cette option active le pare-feu. (GNE = PROXY SOCKS + PARE-FEU)

— Ce noeud est connecté à un réseau local et il est équipé d'un système d'émulation de réseau (ENE).

— Les ENE derrière GNE ne peuvent pas annoncer sur le LAN.

— Vous pouvez envoyer une requête ping, établir une connexion telnet et CTC à GNE et voir tous les ENE derrière GNE.

— Vous ne pouvez pas envoyer de requête ping, telnet ou CTC à ENE.

Si le bouton Activer le proxy Socks est sélectionné.  Et ENE est sélectionné.

— Crée un tunnel SOCKS à construire entre le PC exécutant CTC et le noeud connecté au réseau local.

— Ceci est pour les noeuds qui sont connectés par DCC uniquement.

— Ce paramètre empêche le noeud ENE d'ajouter des routes à la table de routage avec un saut suivant de l'interface LAN (motfcc0 pour 15xxx).

— Vous pouvez envoyer une requête ping aux ENE, sauf si le noeud connecté au réseau local est un GNE SOCKS.

— Un technicien peut envoyer une requête ping, telnet ou CTC à l’ENE s’il est connecté au noeud avec un ordinateur dans le même sous-réseau que l’NE.

Si le bouton Activer le proxy Socks est sélectionné.  Et Socks Proxy Only est sélectionné.

— Crée un tunnel SOCKS à construire entre le PC exécutant CTC et le noeud connecté au réseau local.

— Identique à GNE sauf qu'il n'active pas le pare-feu.

— Le pare-feu est désactivé.

— Vous pouvez envoyer une requête ping et établir une connexion Telnet avec les noeuds.

Si le bouton Enable Socks Proxybutton est sélectionné.  Et Socks Proxy Only est sélectionné.

— Crée un tunnel SOCKS à construire entre le PC exécutant CTC et le noeud connecté au réseau local.

— Identique à GNE sauf qu'il n'active pas le pare-feu.

— Le pare-feu est désactivé.

— Vous pouvez envoyer une requête ping et établir une connexion Telnet avec les noeuds.

Configuration SNMP sur le proxy Socks d'environnement multi-étagère :

- Le LNE doit disposer d'une route statique pour s'annoncer comme passerelle dans la zone DCC.

- Un exemple de route statique est une route statique par défaut, destination 0.0.0.0, tronçon suivant du routeur DCN, cost=10.

- Les noeuds ENE doivent envoyer des interruptions au LNE, port 391.

Numéro MIB

Nom du module

Spécifique à la technologie

1

CERENT-GLOBAL-REGISTRY.mib

Spécifique au 15454

2

CERENT-TC.mib

Spécifique au 15454

3

CERENT-454.mib

Spécifique au 15454

4

CERENT-GENERIC.mib (non applicable à ONS 15454)

Spécifique au 15454

5

CISCO-SMI.mib

Spécifique au 15454

6

CISCO-VOA-MIB.mib

Spécifique au MSTP 15454

7

CERENT-MSDWDM-MIB.mib

8

CISCO-OPTICAL-MONITOR-MIB.mib

9

CERENT-HC-RMON-MIB.mib

Spécifique au 15454

10

CERENT-ENVMON-MIB.mib

Spécifique au 15454

11

CERENT-GENERIC-PM-MIB.mib

Spécifique au 15454

MIB propriétaires :

Cisco ONS 15454 met en oeuvre des MIB spécifiques à l'entreprise ainsi que des MIB standard de l'IETF, tandis que les MIB IETF sont communs aux Cisco 15327 et aux Cisco 15454, ce qui n'est pas le cas des MIB propriétaires. Chaque produit possède un ensemble de trois fichiers MIB propriétaires.

Les fichiers MIB spécifiques à l'entreprise sont disponibles dans SMIv2 (communément appelé 'MIB SNMP version 2') ainsi que dans SMIv1 (communément appelé 'MIB SNMP version 1'). Selon les besoins du NMS, un ensemble approprié de fichiers MIB doit être chargé dans le NMS.

Notez qu'il n'y a aucune différence entre les fichiers MIB SMIv2 et SMIv1, à l'exception de la syntaxe, ce qui signifie qu'il n'aurait aucun impact sur le NMS si les fichiers MIB SMIv1 sont chargés au lieu des fichiers MIB SMIv2, ou vice versa.

Une caractéristique unique de SNMP est qu'une version particulière d'un fichier mib est toujours compatible avec toutes les versions antérieures du même fichier. Par exemple, le fichier CERENT-454-MIB.mib est compatible avec la version logicielle R2.2.3, R2.2.1, R2.0, etc. Il s'agit d'une propriété obligatoire de chaque fichier MIB SNMP et les fichiers MIB propriétaires Cisco ONG ne font pas exception. Par conséquent, lorsque vous avez le choix, chargez les derniers fichiers MIB dans le NMS pour des opérations sans souci.

Fichiers MIB SMIv1/SMIv2 pour Cisco ONS 15454::

1. CERENT-GLOBAL-REGISTRY.mib

2. CERENT-TC.mib

3. CERENT-454-MIB.mib

4. CERENT-MSDWDM-MIB.mib

5. CERENT-OPTICAL-MONITOR-MIB.mib

6. CISCO-SMI.mib*

7. CISCO-OPTICAL-MONITOR-MIB.mib*

8. CISCO-VOA-MIB.mib

Chargement des fichiers MIB dans les plates-formes NMS :

Suivre ces instructions lors du chargement des fichiers MIB SNMP dans un système de gestion de réseau simplifierait et accélérerait les choses.

- Assurez-vous d'abord que vous chargez la version acceptable des fichiers MIB. Par exemple, certaines plates-formes NMS acceptent toujours les fichiers mib SMIv1 (ou 'SNMP version 1') uniquement.

- Les fichiers mib doivent être chargés dans l'ordre indiqué ci-dessus. Si cette commande n'est pas strictement respectée, un ou plusieurs fichiers mib ne seront pas compilés. Ordre de chargement spécifié dans la table de dépendances MIB. Ce tableau ne facilite le chargement que d'un sous-ensemble de fichiers MIB standard IETF si vous le souhaitez.

- Si un ou plusieurs fichiers MIB IETF entraînent des erreurs dans le NMS lors du chargement, contactez le fournisseur du NMS pour résoudre le problème.

Chargement MIB dans le gestionnaire de noeuds réseau HPOV

Récupérez les fichiers MIB SMIv2 depuis le haut et chargez le NNM HPOV (HP OpenView Network Node Manager) dans le bon ordre.

- Assurez-vous que les fichiers mib propriétaires sont chargés dans le NNM. Regardez sous Options dans le panneau NM principal et suivez les options pour charger les fichiers mib.

- Ouvrez ensuite la configuration de l'événement.

- Dans n'importe quelle fenêtre du navigateur d'alarmes, sélectionnez Actions : Configurer l'événement.

- Dans la moitié supérieure de la fenêtre, sélectionnez l'événement cerent454s'il s'agit du système Cisco 15454 et cerentGenericEvent s'il s'agit du système Cisco 15327.

- Dans la moitié inférieure de la fenêtre, sélectionnez une alarme propriétaire que vous voulez configurer dans la fenêtre du navigateur d'alarmes du NNM.

- Sélectionnez Modifier : Événements->Modifier, puis sélectionnez le message d'événement

- Effectuer une sélection dans la catégorie

- Effectuer une sélection dans le champ Gravité, par exemple, Major

- Dans le champ Event Log Messagefield, saisissez ce qui suit :

$N $2 Objet : $3 Index : $4 Emplacement : $5 Port : $6 AID : $8

- Appuyez sur OK, puis enregistrez le travail sous Fichier

- Maintenant chaque déroutement du noeud apparaîtra avec un message et les varbinds qui l'accompagnent.

Par exemple,

« lossOfSignal effacé, objet : ds3 Index : 28449 Emplacement : 3 Port : 1 AID : FAC-5-1 »

- Vous pouvez configurer une action à exécuter lors de la réception de ce déroutement. Il peut également être souhaitable d'avoir ce message ci-dessus sous une forme différente. Ces options peuvent être exercées à l'aide du panneau ci-dessus, si vous le souhaitez.

Table de dépendances MIB :

Le tableau suivant présente les dépendances d'un fichier mib à résoudre lors du chargement dans un NMS.

fichier MIB

Nécessite

BRIDGE-MIB-rfc1493.mib

RFC1155-SMI

RFC1212

RFC1215

RFC1213-MIB-rfc1213.mib

CERENT-454-MIB.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

CERENT-GLOBAL-REGISTRY.mib

CERENT-TC.mib

CERENT-GENERIC-MIB.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

CERENT-GLOBAL-REGISTRY.mib

CERENT-TC.mib

DS1-MIB-rfc2495.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

IF-MIB-rfc2233.mib

PerfHist-TC-MIB-rfc2493.mib

IANAifType-MIB.mib

SNMPv2-MIB-rfc1907.mib

DS3-MIB-rfc2496.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

IF-MIB-rfc2233.mib

PerfHist-TC-MIB-rfc2493.mib

IANAifType-MIB.mib

SNMPv2-MIB-rfc1907.mib

ENTITY-MIB-rfc2737.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

SNMP-FRAMEWORK-MIB-rfc2571.mib

EtherLike-MIB-rfc2358.mib

SNMPv2-SMI

SNMPv2-CONF

SNMPv2-MIB-rfc1907.mib

IANAifType-MIB.mib

IF-MIB-rfc2233.mib

IF-MIB-rfc2233.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

SNMPv2-MIB-rfc1907.mib

IANAifType-MIB.mib

P-BRIDGE-MIB-rfc2674.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

RFC1213-MIB-rfc1213.mib

BRIDGE-MIB-rfc1493.mib

Q-BRIDGE-MIB-rfc2674.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

RFC1213-MIB-rfc1213.mib

BRIDGE-MIB-rfc1493.mib

SNMP-FRAMEWORK-MIB-rfc2571.mib

P-BRIDGE-MIB-rfc2674.mib

RMON-MIB-rfc1757.mib

RMONTOK-rfc1513.mib

RMON2-MIB-rfc2021.mib

RFC1213-MIB-rfc1213.mib

RFC1155-SMI

RFC-1212

RMON-MIB-rfc1757.mib

RFC1155-SMI

RFC-1212

RFC1213-MIB-rfc1213.mib

RFC1215

SONET-MIB-rfc2558.mib

SNMPv2-SMI

SNMPv2-TC

SNMPv2-CONF

SNMPv2-MIB-rfc1907.mib

IANAifType-MIB.mib

IF-MIB-rfc2233.mib

PerfHist-TC-MIB-rfc2493.mib

Gestion des déroutements :

1.Lire le déroutement

2. Identifiez les éléments suivants :

Trap : TrapId

cerent454AlarmObjectType attrValue : ObjectType

cerent454AlarmState attrValue : ServiceAffecting/ Aucun service affecté

cerent454AlarmObjectName : niveau/emplacement/port

Type = IpAddress, Valeur = 10.105.142.205 (V2 uniquement)

3.Parcourez les directives de dépannage / dépannage des alarmes, sélectionnez l'ID de piège approprié et accédez à la section correspondante.

4.Utilisez les informations de niveau/logement/port pour identifier la carte et le port affectés

5.Mettre en oeuvre la procédure et effacer l'alarme.

Exemple de déroutements SNMP V1 :

Interruption SNMPv1 : lossOfSignalForOpticalChannel

(Mer mai 05 11:20:49 2014) Interruption SNMPv1 : IP de l'agent = 10.105.142.205, avec temps = 18 heures : 31 mn: 16,37 s (6667637)

Entreprise = 1.3.6.1.4.1.3607.6.10.30, Générique = EntrepriseSpécifique, Spécifique = perteDeSignalPourOpticalChannel

AttrOid1 = cerent454NodeTime.0, AttrType = OctetString, AttrValue = 20051128022020S

AttrOid2 = cerent454AlarmState.8195.5600, AttrType = Integer, AttrValue = CriticalServiceAffecting(100)

AttrOid3 = cerent454AlarmObjectType.8195.5600, AttrType = Integer, AttrValue = dwdmTrunk(170)

AttrOid4 = cerent454AlarmObjectIndex.8195.5600, AttrType = Integer, AttrValue = 8195

AttrOid5 = cerent454AlarmSlotNumber.8195.5600, AttrType = entier, AttrValue = 2

AttrOid6 = cerent454AlarmPortNumber.8195.5600, AttrType = Integer, AttrValue = port2(20)

AttrOid7 = cerent454AlarmLineNumber.8195.5600, AttrType = Integer, AttrValue = 0

AttrOid8 = cerent454AlarmObjectName.8195.5600, AttrType = OctetString, AttrValue = CHAN-2-2

Varbind 1 dans le piège 1.3.6.1.4.1.3607.6.10.100.10.20.0 : Correspond à la définition MIB.

Varbind 2 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.80.8195.5600 : Correspond à la définition MIB.

Varbind 3 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.20.8195.5600 : Correspond à la définition MIB.

Varbind 4 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.60.8195.5600 : Correspond à la définition MIB.

Varbind 5 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.30.8195.5600 : Correspond à la définition MIB.

Varbind 6 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.40.8195.5600 : Correspond à la définition MIB.

Varbind 7 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.50.8195.5600 : Correspond à la définition MIB.

Varbind 8 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.100.8195.5600 : Correspond à la définition MIB.

Le déroutement est-il une alarme ServiceAffecting ?

Interruption SNMPv1 : lossOfSignalForOpticalChannel

(Mer mai 05 11:20:49 2014) Interruption SNMPv1 : IP de l'agent = 10.105.142.205, avec temps = 18 heures : 31 mn: 16,37 s (6667637)

Entreprise = 1.3.6.1.4.1.3607.6.10.30, Générique = EntrepriseSpécifique, Spécifique = perteDeSignalPourOpticalChannel

AttrOid1 = cerent454NodeTime.0, AttrType = OctetString, AttrValue = 20051128022020S

AttrOid2 = cerent454AlarmState.8195.5600, AttrType = Integer, AttrValue =CriticalServiceAffecting(100)

AttrOid3 = cerent454AlarmObjectType.8195.5600, AttrType = Integer, AttrValue = dwdmTrunk(170)

AttrOid4 = cerent454AlarmObjectIndex.8195.5600, AttrType = Integer, AttrValue = 8195

AttrOid5 = cerent454AlarmSlotNumber.8195.5600, AttrType = entier, AttrValue = 2

AttrOid6 = cerent454AlarmPortNumber.8195.5600, AttrType = Integer, AttrValue = port2(20)

AttrOid7 = cerent454AlarmLineNumber.8195.5600, AttrType = Integer, AttrValue = 0

AttrOid8 = cerent454AlarmObjectName.8195.5600, AttrType = OctetString, AttrValue = CHAN-2-2

Le résultat ci-dessus doit être considéré comme une alarme URGENTE.

Que faire —> Accédez à la ligne directrice de dépannage de Cisco \ Dépannage des alarmes :

http://www.cisco.com/c/en/us/td/docs/optical/15000r9_6/dwdm/troubleshooting/guide/b_454d96_ts.html

Identifiez la cause probable et recherchez-la :

Guide de dépannage

Exemple de déroutements SNMP V2 :

Interruption SNMPv2 : perteDeSignalPourOpticalChannel

(Mer 05 11:20:49 2014) : Interruption SNMPv2 : ID de demande = 254, État d'erreur = Aucune erreur, Index d'erreur = 0

Oid1 = sysUpTime.0, Type = TimeTicks, Value = 116 heures : 48 mn: 23,38 s (42050338)

Oid2 = snmpTrapOID.0, Type = ObjectID, Valeur = 1.3.6.1.4.1.3607.6.10.30.0.5600

Oid3 = cerent454NodeTime.0, Type = OctetString, Valeur = 20051128031653S

Oid4 = cerent454AlarmState.65544.5600, Type = Entier, Valeur = CriticalServiceAffecting(100)

Oid5 = cerent454AlarmObjectType.65544.5600, Type = Entier, Valeur = ots(3210)

Oid6 = cerent454AlarmObjectIndex.65544.5600, Type = Entier, Valeur = 65544

Oid7 = cerent454AlarmSlotNumber.65544.5600, Type = Entier, Valeur = 16

Oid8 = cerent454AlarmPortNumber.65544.5600, Type = Entier, Valeur = port1(10)

Oid9 = cerent454AlarmLineNumber.65544.5600, Type = Entier, Valeur = 0

Oid10 = cerent454AlarmObjectName.65544.5600, Type = OctetString, Valeur = LINE-16-1-RX

Oid11 = 1.3.6.1.6.3.18.1.3.0, Type = IpAddress, Valeur = 10.105.142.205

Varbind 3 dans le piège 1.3.6.1.4.1.3607.6.10.100.10.20.0 : Correspond à la définition MIB.

Varbind 4 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.80.65544.5600 : Correspond à la définition MIB.

Varbind 5 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.20.65544.5600 : Correspond à la définition MIB.

Varbind 6 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.60.65544.5600 : Correspond à la définition MIB.

Varbind 7 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.30.65544.5600 : Correspond à la définition MIB.

Varbind 8 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.40.65544.5600 : Correspond à la définition MIB.

Varbind 9 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.50.65544.5600 : Correspond à la définition MIB.

Varbind 10 dans le piège 1.3.6.1.4.1.3607.6.10.20.30.20.1.100.65544.5600 : Correspond à la définition MIB.

Même procédure :

- La seule différence se trouve dans l'adresse IP source : comment identifier le noeud :

Oid11 = 1.3.6.1.6.3.18.1.3.0, Type = IpAddress, Valeur = 10.105.142.205

- Il fournit l'adresse IP du noeud source.

Documentation pertinente :

- Guide de dépannage pour DWDM :

http://www.cisco.com/c/en/us/td/docs/optical/15000r9_6/dwdm/troubleshooting/guide/b_454d96_ts.html

- Ce lien contient également une explication très utile sur la façon dont le 15454 fournit la gestion SNMP :

http://www.cisco.com/c/en/us/td/docs/optical/15000r9_0/dwdm/reference/guide/454d90_ref/454d90_snmp.html

- Les bases MIB se trouvent sur CCO Cisco Connection Online.

- Le lien suivant contient le module pour les objets et les événements du déroutement reçu du Cisco ONS 15454 :

http://issues.opennms.org/secure/attachment/10480/CERENT-454-MIB.txt