Cómo solucionar problemas de destino snmp que no recibe alertas SNMP enviadas desde Unisphere.

A continuación, se muestran los cuatro lugares para comprobar si un destino SNMP no puede recibir alertas SNMP enviadas desde Unisphere.
 

• La palabra community del destino SNMP del cliente debe coincidir con la palabra de comunidad predeterminada (SNMP_trap) de Unisphere.  
• El cliente debe garantizar una buena conectividad de red entre el servidor Unisphere y el destino de SNMP. Podemos usar los comandos openssl y tracepath en el servidor de Unisphere para verificar la conectividad y usar el comando tcpdump en el servidor de Unisphere para capturar el paquete SNMP durante las pruebas de alerta. Una manera sencilla de demostrar que Unisphere puede enviar alertas SNMP correctamente es tener un destino DE SNMP conectado directamente al servidor de Unisphere. Si el destino SNMP conectado directamente puede recibir alertas SNMP mientras que el no conectado directamente no puede, significa que el problema está en la red del cliente.  
• La configuración de alertas DE SNMP de Unisphere debe estar configurada correctamente, lo que incluye lo siguiente:    
• Configuración de notificación de SNMP, configuración de política de alerta, nivel de notificación.

 
Si lo anterior no tiene problemas, el soporte debe continuar con la prueba de alertas con el registro de depuración se storevntd habilitado, el conjunto de registro smas INFO y tcpdump capturado. Recopile emcgrab y los resultados de las pruebas si no podemos ver evidencia de que las alertas snmp se enviaron correctamente.
Tenga en cuenta que es mejor generar alertas reales que no sea el uso de la función "TEST SNMP" durante la prueba, ya que, en comparación con las alertas reales, el paquete "TEST SNMP" es pequeño y más poco confiable de transmitir para el paquete UDP.

 

Pasos detallados para la solución de problemas: 

1. Palabra de comunidad SNMP.

La palabra de comunidad predeterminada es "SNMP_trap". Si no coincide con la palabra community del destino snmp, podemos cambiarlo agregando la siguiente línea en el archivo se daemon_options:
 

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

Guarde el archivo y reinicie el demonio storevntd para permitir que el cambio surta efecto. (No utilice el comando reload, ya que no es confiable)

stordaemon shutdown storevntd
stordaemon start storevntd

Una vez que storenvtd se reinicia, las políticas de alerta cargadas anteriormente desde la página de configuración de alertas de Unisphere también se pierden. Para permitir que las políticas de alerta se vuelvan a cargar y se registren en storevntd, también debemos reiniciar el servicio smas .
(El siguiente comando es para reiniciar el servicio smas en el servidor Linux. Puede seguir los eventos de SNMP que no se envían al servidor U4V o SNMP integrado para reiniciar el servicio smas para Unisphere integrado).

En el servidor de Unisphere, cd to the path /etc/init.d y, a continuación, ejecute los siguientes comandos:

./smas stop
./smas start

A continuación, podemos usar el comando para comprobar el estado del registro del evento storevntd . (Toma un poco de tiempo para los eventos registrados en storevntd después del reinicio de smas)

stordaemon action storevntd -cmd list -regs –v

 

2. Conectividad de red.

Podemos usar el comando openssl y tracepath en el servidor de Unisphere para comprobar si Unisphere puede comunicarse bien con el destino 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. Configuración de alertas SNMP de Unisphere:

 

1. Configuración de notificación de alertas SNMP.  

Configuración: alertas: notificaciones, haga clic en la palabra "Configurar" en el bloque SNMP y asegúrese de que la dirección IP y el puerto de destino de SNMP correctos estén configurados.

(Nota: Pruebe con un solo destino SNMP para evitar la complejidad de la prueba).



Para verificar si estas configuraciones se cargan correctamente en el demonio storevntd, podemos usar el siguiente comando para comprobar:

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

(Para la alerta de syslog , los dos primeros comandos correspondientes son los siguientes:

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

 

2. Configuración de política de alerta

Más adelante, generaremos una alerta de cambio de configuración de dispositivo real para la prueba de alerta, por lo que aquí utilizaremos la política de "cambio de configuración del dispositivo" como ejemplo. Asegúrese de que "Device Config Change" esté seleccionado para el arreglo utilizado para la prueba de alerta y que el tipo de notificaciones se especifique con SNMP.



 

3. Nivel de notificación

Mediante la creación de un nuevo dispositivo para la prueba de alerta, la alerta que generamos es "La configuración del dispositivo ha cambiado". La alerta se encuentra en el nivel de información, por lo que debemos asegurarnos de que el icono azul esté seleccionado para una prueba de alerta al menos.


 

4. Habilitar el registro de depuración storevntd y el registro de INFORMACIÓN de Unisphere

 Cambie los siguientes parámetros en el archivo se daemon_options:

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

Guarde el archivo, según el paso 1; debemos reiniciar el demonio storevntd y, a continuación, reiniciar el servicio smas .
Después de reiniciar el servicio smas , cambie el nivel de registro de Unisphere a INFO. (Nota: Reiniciar el servicio smas vuelve a cambiar el nivel de registro al valor predeterminado, que es WARN. ).
 

5. Prueba de alerta

Genere una alerta real, utilice tcpdump para capturar el paquete SNMP y comprobar el registro de depuración storevntd . 

1. Ejecute el comando tcpdump en el servidor de Unisphere para prepararse para la captura de paquetes SNMP:

tcpdump -i any udp port 162 

2. Ejecute el siguiente comando para comprobar el contador de eventos de SNMP existente:

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. Cree un LUN de 100 millones en Unisphere. Compruebe el panel de alertas de Unisphere y verá que se genera la alerta "Device configuration has changed". Si no puede ver la alerta emergente, haga clic en el botón Actualizar en la barra superior de la página de Unisphere.

 (Si también habilitó la política "device status", también puede ver que se genera la alerta "Device state has changed to Online" [El estado del dispositivo cambió a En línea]).


 

4. Compruebe la salida de tcpdump.

A continuación, se muestra que la alerta SNMP se capturó correctamente:
 

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. Vuelva a comprobar el contador de eventos. Podemos ver un evento snmp más entregado.

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. Compruebe el registro de depuración storenvtd :

Si puede encontrar las siguientes entradas en el registro, muestra que storevntd ha entregado correctamente la alerta SNMP:

 [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

La evidencia anterior muestra que la alerta SNMP se envió correctamente desde el lado de Unisphere. Si no logramos capturar el paquete SNMP mediante tcpdump y storevntd tampoco tenemos pruebas para la entrega correcta de eventos, recopile emcgrab y comuníquese con el soporte técnico.