Problemen oplossen met SNMP-target die geen SNMP-waarschuwingen ontvangen die vanuit Unisphere worden verzonden.

Hieronder vindt u de vier plaatsen om te controleren of een SNMP-doel geen SNMP-waarschuwingen ontvangt die vanuit Unisphere worden verzonden.
 

• Het communitywoord van het SNMP-doel van de klant moet overeenkomen met het standaard communitywoord (SNMP_trap) van Unisphere.  
• De klant moet zorgen voor goede netwerkconnectiviteit tussen Unisphere-server en SNMP-doel. We kunnen openssl - en tracepath-opdrachten op Unisphere server gebruiken om de connectiviteit te verifiëren en tcpdump-opdracht op Unisphere server te gebruiken om het SNMP-pakket vast te leggen tijdens waarschuwingstests. Een eenvoudige manier om te bewijzen dat Unisphere SNMP-waarschuwingen kan verzenden, is door een SNMP-doel rechtstreeks met de Unisphere-server te verbinden. Als het rechtstreeks verbonden SNMP-doel SNMP-waarschuwingen kan ontvangen terwijl de niet-indirect verbonden niet kan, betekent dit dat het probleem zich in het netwerk van de klant bevindt.  
• De waarschuwingsinstellingen van Unisphere SNMP moeten allemaal correct zijn ingesteld, zoals:    
• SNMP-meldingsconfiguratie, instelling waarschuwingspolicy, meldingsniveau.

 
Als het bovenstaande geen problemen heeft, moet support doorgaan met de waarschuwingstest met ingeschakeld SE storevntd debug log, smas INFO logging set en tcpdump vastgelegd. Verzamel emcgrab en testresultaten als we geen bewijs kunnen zien dat SNMP-waarschuwingen zijn verzonden.
Opmerking: Het is beter om tijdens de test echte waarschuwingen te genereren dan de functie "TEST SNMP" te gebruiken, omdat het 'TEST SNMP'-pakket in vergelijking met echte waarschuwingen klein en onbetrouwbaar is om te verzenden voor het UDP-pakket.

 

Gedetailleerde stappen voor probleemoplossing: 

1. SNMP Community-woord.

Het standaard communitywoord is 'SNMP_trap'. Als het niet overeenkomt met het communitywoord van het SNMP-doel, kunnen we dit wijzigen door de volgende regel toe te voegen aan het SE daemon_options-bestand:
 

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

Sla het bestand op en start de storevntd daemon opnieuw op om de wijziging van kracht te laten worden. (Gebruik de opdracht Reload niet omdat deze niet betrouwbaar is)

stordaemon shutdown storevntd
stordaemon start storevntd

Zodra storenvtd opnieuw is opgestart, gaan ook de waarschuwingspolicy's die eerder zijn geladen vanaf de Unisphere waarschuwingsconfiguratiepagina verloren. Om de waarschuwingspolicy's opnieuw te laden en te registreren in storevntd, moeten we ook de SMAS-service opnieuw starten.
(De onderstaande opdracht is voor het opnieuw starten van de smas-service in de Linux-server. U kunt SNMP-gebeurtenissen volgen die niet worden verzonden naar embedded U4V of SNMP-server om de SMAS-service voor ingebouwde Unisphere opnieuw op te starten).

Cd op Unisphere server naar het pad /etc/init.d en voer vervolgens de volgende opdrachten uit:

./smas stop
./smas start

Vervolgens kunnen we de onderstaande opdracht gebruiken om de status van de storevntd-gebeurtenisregistratie te controleren. (Het duurt even voordat gebeurtenissen die zijn geregistreerd in storevntd nadat de smas opnieuw zijn opgestart)

stordaemon action storevntd -cmd list -regs –v

 

2. Netwerkverbinding.

We kunnen de opdracht openssl en tracepath gebruiken op de Unisphere-server om te controleren of Unisphere goed kan communiceren met het SNMP-doel.
 

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-waarschuwingsinstellingen:

 

1. Configuratie SNMP-meldingsmelding.  

Instellingen - Meldingen - Meldingen, klik op het woord 'Configureren' op het SNMP-blok en zorg ervoor dat het juiste SNMP-doel-IP en de juiste poort zijn geconfigureerd.

(Let op: Test met één SNMP-doel om testcomplexiteit te voorkomen.)



Om te controleren of deze configuraties zijn geladen in storevntd daemon, kunnen we de volgende opdracht gebruiken om te controleren:

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

(Voor syslog-waarschuwingen zijn de eerste twee bijbehorende opdrachten:

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

 

2. Waarschuwingspolicy-instelling

Later gaan we een waarschuwing voor het wijzigen van de configuratie van het apparaat genereren voor de waarschuwingstest, dus hier gebruiken we het beleid "device config change" als voorbeeld. Controleer of 'Device Config Change' is aangevinkt voor de array die wordt gebruikt voor de waarschuwingstest en of het type meldingen is opgegeven met SNMP.



 

3. Meldingsniveau

Door een nieuw apparaat te maken voor de waarschuwingstest, is de waarschuwing die we genereren "Device configuration has changed". De waarschuwing bevindt zich op informatieniveau, dus we moeten ervoor zorgen dat het blauwe pictogram ten minste is geselecteerd voor een waarschuwingstest.


 

4. Schakel storevntd debug log en Unisphere INFO log in

 Wijzig de volgende parameters in het SE daemon_options-bestand:

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

Sla het bestand op volgens stap 1; We moeten storevntd daemon opnieuw opstarten en vervolgens de smas-service opnieuw opstarten.
Nadat de smas-service opnieuw is opgestart, wijzigt u het logboekniveau van Unisphere in INFO. (Opmerking: Door de smas-service opnieuw op te starten, wordt het logboekniveau teruggezet op de standaardwaarde, namelijk WARN. )
 

5. Waarschuwingstest

Genereer een echte waarschuwing, gebruik tcpdump om het SNMP-pakket vast te leggen en het storevntd debug-logboek te controleren. 

1. Voer de tcpdump-opdracht uit op de Unisphere-server om voorbereid te zijn op het vastleggen van het SNMP-pakket:

tcpdump -i any udp port 162 

2. Voer de volgende opdracht uit om de bestaande SNMP-gebeurtenisteller te controleren:

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. Maak een 100M LUN in Unisphere. Controleer het Unisphere waarschuwingspaneel en u ziet dat de melding "Device configuration has changed" wordt gegenereerd. Als u de melding niet kunt zien, klikt u op de knop Vernieuwen op de bovenste balk van de Unisphere-pagina.

 (Als u ook de policy 'Device status' hebt ingeschakeld, kunt u ook zien dat de melding 'Device state has changed to Online' (Apparaatstatus is gewijzigd in Online) wordt gegenereerd).


 

4. Controleer de uitvoer van tcpdump.

Hieronder ziet u dat de SNMP-waarschuwing is vastgelegd:
 

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. Controleer de gebeurtenisteller opnieuw. We kunnen nog een snmp-gebeurtenis zien.

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. Controleer het foutopsporingslogboek van de storenvtd :

Als u de volgende vermeldingen in het logboek kunt vinden, wordt weergegeven dat storevntd de SNMP-waarschuwing heeft geleverd:

 [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

Het bovenstaande bewijs toont aan dat de SNMP-waarschuwing is verzonden vanaf de Unisphere-kant. Als we het SNMP-pakket niet kunnen vastleggen met tcpdump en storevntd ook geen bewijs hebben voor een geslaagde levering van het evenement, verzamelt u de emcgrab en schakelt u technische support in.