Slik feilsøker du SNMP-målet som ikke mottar SNMP-varsler sendt fra Unisphere.

Nedenfor finner du fire steder du kan kontrollere om et SNMP-mål ikke mottar SNMP-varsler sendt fra Unisphere.
 

• Fellesskapsordet til kundens SNMP-mål skal samsvare med standard fellesskapsordet (SNMP_trap) i Unisphere.  
• Kunden må sikre god nettverkstilkobling mellom Unisphere-serveren og SNMP-målet. Vi kan bruke opensl- og tracepath-kommandoer på Unisphere-serveren til å verifisere tilkoblingen og bruke tcpdump-kommandoen på Unisphere-serveren til å registrere SNMP-pakken under varslingstester. En enkel måte å bevise at Unisphere kan sende ut SNMP-varsler på, er å ha et SNMP-mål direkte koblet til Unisphere-serveren. Hvis det direkte tilkoblede SNMP-målet kan motta SNMP-varsler mens det ikke er direkte tilkoblet, betyr det at problemet ligger i kundens nettverk.  
• Innstillingene for Unisphere SNMP-varsel skal være riktig angitt, som inkluderer:    
• SNMP-varslingskonfigurasjon, varslingspolicyinnstilling, varslingsnivå.

 
Hvis de ovennevnte ikke har noen problemer, må støtte fortsette med varslingstest med SE storevntd debug log enabled, smas INFO logging set, og tcpdump fanget. Samle inn emcgrab og testresultatene hvis vi ikke kan se bevis på at SNMP-varsler er sendt ut.
Vær oppmerksom på at det er bedre å generere reelle varsler annet enn å bruke TEST SNMP-funksjonen under testen. Sammenlignet med reelle varsler er TEST SNMP-pakken liten og mer upålitelig å overføre for UDP-pakken.

 

Detaljert fremgangsmåte for feilsøking: 

1. SNMP-fellesskapets ord.

Standard gruppeord er "SNMP_trap". Hvis det ikke samsvarer med fellesskapsordet til SNMP-målet, kan vi endre det ved å legge til følgende linje i SE daemon_options-filen:
 

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

Lagre filen, og start deretter storevntd daemon på nytt for å la endringen tre i kraft. (Du må ikke bruke kommandoen for å laste inn på nytt fordi den ikke er pålitelig)

stordaemon shutdown storevntd
stordaemon start storevntd

Når storenvtd startes på nytt, går varslingspolicyene som tidligere ble lastet inn fra unisphere-varselkonfigurasjonssiden, også tapt. For at varslingspolicyene skal kunne lastes inn på nytt og registreres i storevntd, må vi også starte smas-tjenesten på nytt.
(Kommandoen nedenfor er for å starte SMA-tjenesten på nytt i Linux-serveren. Du kan følge SNMP-hendelser som ikke sendes til den innebygde U4V- eller SNMP-serveren for å starte SMA-tjenesten på nytt for innebygd Unisphere).

På Unisphere-serveren , cd til banen /etc/init.d, og kjør deretter følgende kommandoer:

./smas stop
./smas start

Deretter kan vi bruke kommandoen nedenfor for å kontrollere registreringsstatusen for storevntd-hendelsen . (Det tar litt tid for hendelser som er registrert i storevntd etter omstart av smas)

stordaemon action storevntd -cmd list -regs –v

 

2. Nettverkstilkobling.

Vi kan bruke opensl- og tracepath-kommandoen på Unisphere-serveren til å kontrollere om Unisphere kan kommunisere med SNMP-målet på en god måte.
 

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. Innstillinger for Unisphere SNMP-varsel:

 

1. Konfigurasjon av SNMP-varselvarsling.  

Settings - Alerts - Notifications, click on the "Configure" word on the SNMP block and ensure that the correct SNMP target IP and port are configured (Innstillinger – varsler – varsler, klikk på "Konfigurer"-ordet på SNMP-blokken og kontroller at riktig SNMP-mål-IP og -port er konfigurert.

(Merk: Test med ett enkelt SNMP-mål for å unngå testkompleksitet.)



Hvis du vil kontrollere om disse konfigurasjonene er lastet inn i storevntd daemon, kan vi bruke følgende kommando til å kontrollere:

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

(for syslog-varselet er de to første tilsvarende kommandoene:

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

 

2. Policyinnstilling for varsel

Senere skal vi generere et varsel om endring av en ekte enhetskonfigurasjon for varseltesten, så her bruker vi policyen «device config change» (endring av enhetskonfigurasjon) som eksempel. Kontroller at "Device Config Change" (Enhetskonfigurasjonsendring) er merket av for arrayet som brukes for varseltesten, og at varslingstypen er spesifisert med SNMP.



 

3. Varslingsnivå

Ved å opprette en ny enhet for varseltesten, er varselet vi genererer "Device configuration has changed" (Enhetskonfigurasjonen er endret). Varselet er på informasjonsnivå, så vi må sørge for at det blå ikonet er valgt for minst en varseltest.


 

4. Aktiver feilsøkingslogg for storevntd og Unisphere INFO-logg

 Endre følgende parametere i SE daemon_options-fil:

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

Lagre filen i henhold til trinn 1. Vi må starte storevntd daemon på nytt og deretter starte smas-tjenesten på nytt.
Når smas-tjenesten er startet på nytt, endrer du loggingsnivået for Unisphere til INFO. (Merk: Omstart av smas-tjenesten endrer loggingsnivået tilbake til standard, som er WARN. )
 

5. Varseltest

Generer et ekte varsel, bruk tcpdump til å hente SNMP-pakken, og kontroller feilsøkingsloggen for storevntd . 

1. Kjør tcpdump-kommandoen på Unisphere-serveren for å gjøre deg klar for opphenting av SNMP-pakke:

tcpdump -i any udp port 162 

2. Kjør følgende kommando for å kontrollere eksisterende SNMP-hendelsesteller:

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. Opprett en 100 M LUN i Unisphere. Kontroller Unisphere-varselpanelet, og du ser at varselet «Device configuration has changed» (Enhetskonfigurasjon er endret) genereres. Hvis du ikke kan se varselet, klikker du på oppdateringsknappen på øverste linje på Unisphere-siden.

 (Hvis du også aktiverte «enhetsstatus»-policyen, kan du også se at varselet «Device state has changed to Online» (Enhetsstatus er endret til Internett) genereres).


 

4. Kontroller utdataene for tcpdump.

Følgende viser at SNMP-varselet er registrert:
 

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. Kontroller hendelsestelleren på nytt. Vi kan se en ny snmp-hendelse som leveres.

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. Kontroller feilsøkingsloggen for Storenvtd :

Hvis du finner følgende oppføringer i loggen, viser det at storevntd har levert SNMP-varselet:

 [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

Beviset ovenfor viser at SNMP-varselet er sendt ut fra Unisphere-siden. Hvis vi ikke klarer å hente SNMP-pakken ved hjelp av tcpdump og storevntd , har vi heller ikke bevis for vellykket hendelseslevering, samle inn emcgrab og ta kontakt med teknisk støtte.