Dépannage de la cible SNMP qui ne reçoit pas d’alertes SNMP envoyées par Unisphere.

Vous trouverez ci-dessous les quatre emplacements pour vérifier si une cible SNMP ne parvient pas à recevoir les alertes SNMP envoyées par Unisphere.
 

• Le mot de communauté de la cible SNMP du client doit correspondre au mot de communauté par défaut (SNMP_trap) de Unisphere.  
• Le client doit garantir une bonne connectivité réseau entre le serveur Unisphere et la cible SNMP. Nous pouvons utiliser les commandes openssl et tracepath sur le serveur Unisphere pour vérifier la connectivité et utiliser la commande tcpdump sur le serveur Unisphere pour capturer le package SNMP lors des tests d’alerte. Un moyen simple de prouver que Unisphere peut envoyer des alertes SNMP avec succès consiste à avoir une cible SNMP directement connectée au serveur Unisphere. Si la cible SNMP directement connectée peut recevoir des alertes SNMP alors que la cible non connectée ne peut pas, cela signifie que le problème provient du réseau du client.  
• Les paramètres d’alerte SNMP Unisphere doivent tous être définis correctement, notamment :    
• Configuration des notifications SNMP, paramètre de stratégie d’alerte, niveau de notification.

 
Si les éléments ci-dessus ne présentent aucun problème, le support doit procéder au test des alertes avec le log de débogage SE storevntd activé, le jeu de journalisation smas INFO et tcpdump capturé. Collectez emcgrab et les résultats des tests si nous ne pouvons pas voir de preuves que les alertes SNMP ont bien été envoyées.
Notez qu’il est préférable de générer des alertes réelles autres que l’utilisation de la fonction « TEST SNMP » pendant le test, car par rapport aux alertes réelles, le package « TEST SNMP » est petit et peu fiable à transmettre pour le package UDP.

 

Étapes détaillées de dépannage : 

1. Mot de communauté SNMP.

Le mot de communauté par défaut est « SNMP_trap ». S’il ne correspond pas au mot de communauté de la cible SNMP, nous pouvons le modifier en ajoutant la ligne suivante dans le fichier daemon_options SE :
 

storevntd: snmp_trap_community=        
(example: storevntd: snmp_trap_community=public)

Enregistrez le fichier, puis redémarrez le processus storevntd pour que la modification prenne effet. (N’utilisez pas la commande de rechargement, car elle n’est pas fiable)

stordaemon shutdown storevntd
stordaemon start storevntd

Une fois storenvtd redémarré, les stratégies d’alerte précédemment chargées à partir de la page de configuration des alertes Unisphere sont également perdues. Pour que les stratégies d’alerte soient rechargées et enregistrées dans storevntd, nous devons également redémarrer le service smas .
(La commande ci-dessous permet de redémarrer le service smas sur le serveur Linux. Vous pouvez suivre les événements SNMP qui ne sont pas envoyés au serveur U4V ou SNMP intégré pour redémarrer le service smas pour Unisphere intégré).

Sur le serveur Unisphere, effectuez un cd vers le chemin /etc/init.d, puis exécutez les commandes suivantes :

./smas stop
./smas start

Ensuite, nous pouvons utiliser la commande ci-dessous pour vérifier l’état de l’enregistrement des événements storevntd . (Cela prend un peu de temps pour les événements enregistrés dans storevntd après le redémarrage de smas)

stordaemon action storevntd -cmd list -regs –v

 

2. Connectivité réseau.

Nous pouvons utiliser la commande openssl et tracepath sur le serveur Unisphere pour vérifier si Unisphere peut bien communiquer avec la cible SNMP.
 

openssl s_client  -connect :

tracepath : 
(in some version of tracepath, the format is “tracepath /” )

Examples:

openssl s_client  -connect xx.xxx.0.xx:162
Connected

tracepath xx.xxx.0.xx -p 162

1?: [LOCALHOST]                                        pmtu 1500
1:  xxx.1x.xxx.xx0                                        0.854ms
1:  xxx.x8.xxx.xx0                                        0.540ms
2:  xx.xx1.xx.x                                             18.572ms
3:  xx.xxx.0.xx                                             0.988ms reached

 

3. Paramètres d’alerte SNMP Unisphere :

 

1. Configuration des notifications d’alerte SNMP.  

Paramètres - Alertes - Notifications, cliquez sur le mot « Configurer » sur le bloc SNMP et assurez-vous que l’adresse IP et le port cibles SNMP appropriés sont configurés.

(Remarque : Testez avec une seule cible SNMP pour éviter la complexité des tests.)



Pour vérifier si ces configurations sont correctement chargées dans le processus storevntd, nous pouvons utiliser la commande suivante pour vérifier :

stordaemon getvar storevntd -name smas_log_event_targets

storevntd                     smas_log_event_targets=snmp

stordaemon getvar storevntd -name snmp_host

storevntd                     snmp_host=O:xx.xx.xxx.xx:162:v1

stordaemon action storevntd -cmd list -log_targets

(Pour l’alerte syslog , les deux premières commandes correspondantes sont les suivantes :

stordaemon getvar storevntd -name log_event_syslog_host
stordaemon getvar storevntd -name log_event_syslog_port

 

2. Paramètre de stratégie d’alerte

Plus tard, nous allons générer une véritable alerte de modification de configuration de périphérique pour le test d’alerte. Ici, nous utilisons la règle « device config change » à titre d’exemple. Assurez-vous que « Device Config Change » (Modification de la configuration des périphériques) est vérifié pour la baie utilisée pour le test d’alerte et que le type de notifications est spécifié avec SNMP.



 

3. Niveau de notification

En créant un nouveau périphérique pour le test d’alerte, l’alerte que nous générons est « Device configuration has changed ». L’alerte est au niveau des informations. Nous devons donc nous assurer que l’icône bleue est sélectionnée pour un test d’alerte au moins.


 

4. Activer le journal de débogage storevntd et le journal Unisphere INFO

 Modifiez les paramètres suivants dans le fichier daemon_options SE :

storevntd:LOG_LEVEL = debug
storevntd:LOGFILE_TYPE = dated
storevntd:LOGFILE_RETENTION = 7

Enregistrez le fichier, conformément à l’étape 1 ; nous devons redémarrer le processus storevntd , puis redémarrer le service smas .
Une fois le service smas redémarré, définissez le niveau de consignation d’Unisphere sur INFO. (Remarque : Le redémarrage du service smas rétablit le niveau de consignation par défaut, qui est WARN. )
 

5. Test d’alerte

Générez une alerte réelle, utilisez tcpdump pour capturer le package SNMP et vérifiez le journal de débogage storevntd . 

1. Exécutez la commande tcpdump sur le serveur Unisphere pour vous préparer à la capture du package SNMP :

tcpdump -i any udp port 162 

2. Exécutez la commande suivante pour vérifier le compteur d’événements SNMP existant :

stordaemon action storevntd -cmd list -log_stats

storevntd                     Event Loggers
file             : 0 events delivered
system           : 0 events delivered
syslog           : 17 events delivered
snmp             : 4 events delivered

3. Créez une LUN de 100 M dans Unisphere. Vérifiez le panneau d’alerte Unisphere et vous voyez que l’alerte « Device configuration has changed » est générée. Si l’alerte ne s’affiche pas, cliquez sur le bouton Actualiser dans la barre supérieure de la page Unisphere.

 (Si vous avez également activé la règle « Device status », vous pouvez également voir que l’alerte « Device state has changed to Online » est générée.


 

4. Vérifiez la sortie de tcpdump.

Les éléments suivants montrent que l’alerte SNMP a été capturée avec succès :
 

tcpdump -i any udp port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:05:59.246606 IP MGMT-0.emc-gateway > xx.xxx.xx.xxx.snmptrap:  C="SNMP_trap" Trap(448)  E:1139.3 xx.xxx.xx.xxx enterpriseSpecific s=4 0 X:xx.1.xx.1.8.xx.6.4.xxx.xxx.8x.xxx.6x.0.0.0.0.0.0.0.0.7=7 X:xx.1.11.1.7.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0.7=2 X:xx.1.xx.1.8.xx.6.4.xxx.xxx.8x.xxx.6x.0.0.0.0.0.0.0.0.7=.0.0 X:xx.1.11.1.9.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0.7="Symmetrix 000xxxx0xxxx : Device configuration has changed. - Object is: 000xxxx0xxxx:00867" X:xx.1.xx.1.6.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0.7=8 X:xx.1.6.1.20.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0="000xxxx0xxxx" X:xx.1.6.1.3.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0=11 E:1139.3.8888.1.0=2 E:1139.3.8888.2.0=5000 E:1139.3.8888.3.0=0 E:1139.3.8888.4.0="" 

5. Vérifiez à nouveau le compteur d’événements. Nous pouvons voir un autre événement snmp livré.

stordaemon action storevntd -cmd list -log_stats

storevntd                     Event Loggers
file             : 0 events delivered
system           : 0 events delivered
syslog           : 17 events delivered
snmp             : 5 events delivered

6. Vérifiez le journal de débogage storenvtd  :

Si vous pouvez trouver les entrées suivantes dans le journal, le message storevntd indique que l’alerte SNMP a été correctement émise :

 [4964             EvtLogger] Feb-15 11:05:59.246 : [sendTrapForEach()] Trap sent to xx.xxx.xx.xxx, port 162

 [4964             EvtLogger] Feb-15 11:05:59.246 : [processOneSymmEvent()] Symmetrix 000xxxxxxx1 : Device configuration has changed. - Object is: 000xxxxxxxx1:00024
 [4964             EvtLogger] Feb-15 11:05:59.246 : [processAsyncEvent()] Function Exit, rc= 470
 [4964             EvtLogger] Feb-15 11:05:59.246 : [evtd_logLoggerThrd] Event Delivery complete

Les preuves ci-dessus montrent que l’alerte SNMP a été envoyée avec succès du côté Unisphere. Si nous ne parvenons pas à capturer le package SNMP à l’aide de tcpdump et storevntd , nous ne disposons pas non plus de preuves d’une livraison réussie de l’événement, collectez emcgrab et contactez le support technique.