Gestion des pannes SNMP MSTP ONS 15454
Contenu
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::
- CERENT-GLOBAL-REGISTRY.mib
- CERENT-TC.mib
- CERENT-454-MIB.mib
- CERENT-MSDWDM-MIB.mib
- CERENT-OPTICAL-MONITOR-MIB.mib
- CISCO-SMI.mib*
- CISCO-OPTICAL-MONITOR-MIB.mib*
- 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 :
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 :
- 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
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)