Come risolvere i problemi di destinazione SNMP che non riceve avvisi SNMP inviati da Unisphere.

Di seguito sono riportate le quattro posizioni in cui verificare se una destinazione SNMP non riesce a ricevere avvisi SNMP inviati da Unisphere.
 

• La community word della destinazione SNMP del cliente deve corrispondere alla parola della community predefinita (SNMP_trap) di Unisphere.  
• Il cliente deve garantire una buona connettività di rete tra il server Unisphere e la destinazione SNMP. È possibile utilizzare i comandi openssl e tracepath sul server Unisphere per verificare la connettività e utilizzare il comando tcpdump sul server Unisphere per acquisire il pacchetto SNMP durante i test degli avvisi. Un modo semplice per dimostrare che Unisphere può inviare avvisi SNMP correttamente è quello di avere una destinazione SNMP connessa direttamente al server Unisphere. Se la destinazione SNMP connessa direttamente può ricevere avvisi SNMP mentre non è connessa direttamente, significa che il problema riguarda la rete del cliente.  
• Le impostazioni degli avvisi SNMP unisphere devono essere tutte impostate correttamente, tra cui:    
• Configurazione delle notifiche SNMP, impostazione dei criteri di avviso, livello di notifica.

 
Se quanto indicato sopra non presenta problemi, il supporto deve procedere con il test degli avvisi con il registro di debug storevntd SE abilitato, il set di registrazione smas INFO e l'acquisizione di tcpdump . Raccogliere emcgrab e i risultati dei test se non è possibile verificare che gli avvisi SNMP siano stati inviati correttamente.
Si noti che è preferibile generare avvisi reali anziché utilizzare la funzione "TEST SNMP" durante il test, perché rispetto agli avvisi reali, il pacchetto "TEST SNMP" è piccolo e più inaffidabile per la trasmissione per il pacchetto UDP.

 

Procedura dettagliata per la risoluzione dei problemi: 

1. Parola della community SNMP.

La parola predefinita della community è "SNMP_trap". Se non corrisponde alla parola della community della destinazione SNMP, è possibile modificarla aggiungendo la seguente riga nel file daemon_options SE:
 

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

Salvare il file, quindi riavviare il daemon storevntd per rendere effettiva la modifica. Non utilizzare il comando di ricarica poiché non è affidabile.

stordaemon shutdown storevntd
stordaemon start storevntd

Una volta riavviato storenvtd , anche le policy di avviso caricate in precedenza dalla pagina di configurazione degli avvisi di Unisphere vengono perse. Per consentire il caricamento e la registrazione delle policy di avviso in storevntd, è necessario riavviare anche il servizio smas .
(il comando riportato di seguito è per riavviare il servizio smas nel server Linux. È possibile seguire che gli eventi SNMP non vengono inviati al server Embedded U4V o SNMP per riavviare il servizio smas per Unisphere integrato.

Sul server Unisphere, accedere al percorso /etc/init.d, quindi eseguire i seguenti comandi:

./smas stop
./smas start

Quindi è possibile utilizzare il comando riportato di seguito per controllare lo stato di registrazione dell'evento storevntd . (Ci vuole un po' di tempo per gli eventi registrati in storevntd dopo il riavvio di smas)

stordaemon action storevntd -cmd list -regs –v

 

2. Connettività di rete.

È possibile utilizzare il comando openssl e tracepath sul server Unisphere per verificare se Unisphere è in grado di comunicare bene con la destinazione 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. Impostazioni degli avvisi SNMP Unisphere:

 

1. Configurazione delle notifiche di avviso SNMP.  

Impostazioni - Avvisi - Notifiche, fare clic sulla parola "Configura" sul blocco SNMP e assicurarsi che siano configurati l'IP e la porta di destinazione SNMP corretti.

(Nota: Eseguire un test con una singola destinazione SNMP per evitare complessità di test.



Per verificare se queste configurazioni sono state caricate correttamente nel daemon storevntd, è possibile utilizzare il seguente comando per verificare:

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

(per l'avviso syslog , i primi due comandi corrispondenti sono:

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

 

2. Impostazione dei criteri di avviso

In seguito genereremo un avviso reale di modifica della configurazione del dispositivo per il test degli avvisi, quindi qui utilizzeremo la policy "device config change" come esempio. Verificare che sia selezionata l'opzione "Device Config Change" per l'array utilizzato per il test degli avvisi e che il tipo di notifica sia specificato con SNMP.



 

3. Livello di notifica

Creando un nuovo dispositivo per il test degli avvisi, l'avviso generato è "Device configuration has changed". L'avviso è a livello di informazioni, quindi è necessario assicurarsi che l'icona blu sia selezionata almeno per un test di avviso.


 

4. Abilitare il registro di debug storevntd e il registro INFO di Unisphere

 Modificare i seguenti parametri nel file daemon_options SE:

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

Salvare il file, come indicato nel passaggio 1; è necessario riavviare il daemon storevntd e quindi il servizio smas .
Dopo aver riavviato il servizio smas , modificare il livello di registrazione di Unisphere in INFO. Nota: Il riavvio del servizio smas riporta il livello di registrazione all'impostazione predefinita, che è WARN. )
 

5. Test avvisi

Generare un avviso reale, utilizzare tcpdump per acquisire il pacchetto SNMP e controllare il registro di debug storevntd . 

1. Eseguire il comando tcpdump sul server Unisphere per prepararsi all'acquisizione del pacchetto SNMP:

tcpdump -i any udp port 162 

2. Eseguire il comando seguente per controllare il contatore degli eventi SNMP esistente:

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. Creare una LUN da 100 milioni in Unisphere. Controllare il pannello degli avvisi di Unisphere e verificare che venga generato l'avviso "Device configuration has changed". Se non viene visualizzato il pop-out dell'avviso, cliccare sul pulsante Refresh nella barra superiore della pagina di Unisphere.

 Se è stato abilitato anche il criterio "device status", è possibile visualizzare l'avviso "Device state has changed to Online".


 

4. Controllare l'output di tcpdump.

La seguente tabella mostra che l'avviso SNMP è stato acquisito correttamente:
 

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. Controllare nuovamente il contatore degli eventi. Possiamo vedere un altro evento SNMP erogato.

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. Controllare il registro di debug storenvtd :

Se nel registro sono presenti le seguenti voci, storevntd ha inviato correttamente l'avviso 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 prova sopra mostra che l'avviso SNMP è stato inviato correttamente dal lato Unisphere. Se non si riesce ad acquisire il pacchetto SNMP utilizzando tcpdump e storevntd , inoltre, non è dimostrato che l'erogazione di un evento sia riuscita, raccogliere emcgrab e coinvolgere il supporto tecnico.