Felsöka SNMP-mål som inte tar emot SNMP-varningar som skickats från Unisphere.

Nedan finns de fyra platserna för att kontrollera om ett SNMP-mål inte kan ta emot SNMP-varningar som skickats från Unisphere.
 

• Gruppordet i kundens SNMP-mål ska matcha Unispheres standardord (community word) (SNMP_trap).  
• Kunden måste säkerställa en bra nätverksanslutning mellan Unisphere-servern och SNMP-målet. Vi kan använda opensl- och tracepath-kommandon på Unisphere-servern för att verifiera anslutningen och använda kommandot tcpdump på Unisphere-servern för att fånga SNMP-paketet under varningstest. Ett enkelt sätt att bevisa att Unisphere kan skicka SNMP-varningar är att ha ett SNMP-mål direkt anslutet till Unisphere-servern. Om det direktanslutna SNMP-målet kan ta emot SNMP-varningar medan den inte indirekt ansluts innebär det att problemet ligger hos kundens nätverk.  
• Unisphere SNMP-varningsinställningarna bör vara korrekt inställda, inklusive:    
• SNMP-meddelandekonfiguration, inställning av varningspolicy, meddelandenivå.

 
Om ovanstående inte har några problem måste supporten fortsätta med varningstest med SE storevntd-felsökningslogg aktiverad, smas INFO-loggning inställd och tcpdump infångad. Samla in emcgrab och testresultat om vi inte kan se bevis på att SNMP-varningar har skickats ut.
Observera att det är bättre att generera verkliga varningar förutom att använda funktionen "TEST SNMP" under testet, eftersom paketet "TEST SNMP" är litet och mer otillförlitligt att överföra för UDP-paketet jämfört med verkliga varningar.

 

Detaljerade steg för felsökning: 

1. SNMP Community-ord.

Standardordet för community är "SNMP_trap". Om det inte överensstämmer med gruppordet för SNMP-målet kan vi ändra det genom att lägga till följande rad i SE daemon_options-filen:
 

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

Spara filen och starta sedan om storevntd-daemon för att ändringen ska börja gälla. (Använd inte kommandot reload eftersom det inte är tillförlitligt)

stordaemon shutdown storevntd
stordaemon start storevntd

När storenvtd har startats om försvinner även de varningsprinciper som tidigare lästs in från konfigurationssidan för Unisphere-varningar. För att varningsprinciperna ska kunna läsas in och registreras i storevntd måste vi även starta om smas-tjänsten .
(Kommandot nedan är för att starta om smas-tjänsten i Linux-servern. Du kan följa SNMP-händelser som inte skickas till Embedded U4V- eller SNMP-servern för att starta om smas-tjänsten för inbäddade Unisphere).

På Unisphere-servern cd-ansluter du till sökvägen /etc/init.d och kör sedan följande kommandon:

./smas stop
./smas start

Sedan kan vi använda kommandot nedan för att kontrollera registreringsstatus för storevntd-händelsen . (Det tar lite tid för händelser som registrerats i storevntd efter SMAS-omstart)

stordaemon action storevntd -cmd list -regs –v

 

2. Nätverksanslutning.

Vi kan använda kommandot openssl och tracepath på Unisphere-servern för att kontrollera om Unisphere kan kommunicera väl med SNMP-målet.
 

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. Unisphere SNMP-varningsinställningar:

 

1. Konfiguration av SNMP-varningsmeddelanden.  

Settings - Alerts - Notifications, klicka på ordet "Configure" på SNMP-blocket och kontrollera att rätt SNMP-mål-IP och -port är konfigurerade.

(Obs! Testa med ett enda SNMP-mål för att undvika testkomplexitet.)



Om du vill kontrollera att dessa konfigurationer har lästs in i storevntd-daemon kan vi använda följande kommando för att kontrollera:

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

(för syslog-varningar är de första två motsvarande kommandona:

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

 

2. Varningsprincipinställning

Senare genererar vi en varning om ändring av enhetskonfiguration för varningstestet, så här använder vi policyn "device config change" som exempel. Kontrollera att "Device Config Change" är markerat för det disksystem som används för varningstestet och att aviseringstypen anges med SNMP.



 

3. Aviseringsnivå

Genom att skapa en ny enhet för varningstestet genereras varningen "Device configuration has changed". Varningen är på informationsnivå, så vi måste se till att den blå ikonen är vald för ett varningstest åtminstone.


 

4. Aktivera felsökningslogg för storevntd och Unisphere INFO-logg

 Ändra följande parametrar i SE daemon_options-filen:

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

Spara filen enligt steg 1: Vi måste starta om storevntd-daemon och sedan starta om smas-tjänsten .
När smas-tjänsten har startats om ändrar du loggningsnivån för Unisphere till INFO. (Obs! Om du startar om smas-tjänsten ändras loggningsnivån tillbaka till standardvärdet, vilket är WARN. )
 

5. Varningstest

Generera en riktig varning, använd tcpdump för att fånga SNMP-paketet och kontrollera storevntd-felsökningsloggen . 

1. Kör tcpdump-kommandot på Unisphere-servern för att göra dig redo för insamling av SNMP-paketet:

tcpdump -i any udp port 162 

2. Kör följande kommando för att kontrollera den befintliga SNMP-händelseräknaren:

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. Skapa en LUN på 100 M i Unisphere. Kontrollera Unisphere-varningspanelen så visas varningen "Device configuration has changed" (enhetskonfigurationen har ändrats). Om du inte kan se att varningen visas klickar du på uppdateringsknappen i det övre fältet på Unispheres sida.

 (Om du även har aktiverat policyn "device status" kan du även se att varningen "Device state has changed to Online" genereras).


 

4. Kontrollera utdata från tcpdump.

Följande visar att SNMP-varningen har hämtats:
 

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. Kontrollera händelseräknaren igen. Ytterligare en snmp-händelse kan levereras.

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. Kontrollera storenvtd-felsökningsloggen :

Om du hittar följande poster i loggen visas att storevntd har levererat SNMP-varningen:

 [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

Ovanstående bevis visar att SNMP-varningen har skickats ut från Unisphere-sidan. Om vi misslyckas med att registrera SNMP-paketet med tcpdump och storevntd inte heller har bevis för lyckad händelseleverans samlar du in emcgrab och anlitar teknisk support.