Як усунути неполадки, через які ціль SNMP не отримує сповіщення SNMP, надіслані з Unisphere.

Нижче наведено чотири місця, де можна перевірити, чи ціль SNMP не отримує сповіщення SNMP, надіслані з Unisphere.
 

• Слово спільноти цільового об'єкта SNMP клієнта має збігатися зі словом спільноти за замовчуванням (SNMP_trap) Unisphere.  
• Клієнт повинен забезпечити хороше мережеве з'єднання між сервером Unisphere і цільовим об'єктом SNMP. Ми можемо використовувати команди openssl і tracepath на сервері Unisphere для перевірки з'єднання та використовувати команду tcpdump на сервері Unisphere для захоплення пакета SNMP під час тестів оповіщення. Простий спосіб довести, що Unisphere може успішно надсилати сповіщення SNMP, — це мати ціль SNMP, підключену безпосередньо до сервера Unisphere. Якщо безпосередньо підключений об'єкт SNMP може отримувати сповіщення SNMP, а непрямий – ні, це означає, що проблема пов'язана з мережею клієнта.  
• Налаштування оповіщення Unisphere SNMP повинні бути налаштовані правильно, а саме:    
• Конфігурація сповіщень SNMP, Налаштування політики сповіщень, Рівень сповіщень.

 
Якщо у вищезазначеному випадку немає проблем, підтримка повинна продовжити перевірку сповіщень з увімкненим журналом налагодження SE storevntd , набором журналювання smas INFO та захопленням tcpdump . Збираємо emcgrab і результати тестів, якщо ми не бачимо доказів того, що сповіщення SNMP були успішно розіслані.
Зверніть увагу, що краще генерувати реальні оповіщення, а не використовувати функцію "TEST SNMP" під час тесту, тому що в порівнянні з реальними сповіщеннями, пакет "TEST SNMP" невеликий і більш ненадійний для передачі для пакета UDP.

 

Детальні кроки для усунення несправностей: 

1. Слово спільноти SNMP.

Типовим словом спільноти є "SNMP_trap". Якщо він не збігається зі словом спільноти цілі SNMP, ми можемо змінити його, додавши наступний рядок у файл SE daemon_options:
 

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

Збережіть файл, а потім перезапустіть фонову службу storevntd , щоб зміни набули чинності. (Не використовуйте команду reload, оскільки вона ненадійна)

stordaemon shutdown storevntd
stordaemon start storevntd

Після перезапуску storenvtd політики оповіщень, раніше завантажені зі сторінки налаштувань оповіщення Unisphere, також втрачаються. Для того, щоб політики сповіщень були перезавантажені та зареєстровані у storevntd, ми також повинні перезапустити службу smas .
(Наведена нижче команда призначена для перезапуску служби smas на сервері Linux. Ви можете стежити за тим, що події SNMP не надсилаються на сервер Embedded U4V або SNMP , щоб перезапустити службу smas для вбудованої Unisphere).

На сервері Unisphere перейдіть до шляху / etc/init.d, а потім виконайте такі команди:

./smas stop
./smas start

Тоді ми можемо скористатися наведеною нижче командою, щоб перевірити статус реєстрації події storevntd . (Події, зареєстровані у storevntd після перезапуску smas, потребують деякого часу)

stordaemon action storevntd -cmd list -regs –v

 

2. Підключення до мережі.

Ми можемо використовувати openssl і tracepath на сервері Unisphere, щоб перевірити, чи може Unisphere добре взаємодіяти з цільовим об'єктом 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. Налаштування оповіщення Unisphere SNMP:

 

1. Конфігурація сповіщень про оповіщення SNMP.  

Налаштування - Оповіщення - Сповіщення, натисніть на слово "Налаштувати" на блоці SNMP і переконайтеся, що налаштовано правильний цільовий IP і порт SNMP.

(Примітка. Тестуйте з однією ціллю SNMP, щоб уникнути складності тесту.)



Щоб перевірити, чи успішно завантажено ці конфігурації в фонову службу storevntd, ми можемо скористатися наступною командою для перевірки:

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

(Для оповіщення syslog першими двома відповідними командами є:

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

 

2. Налаштування політики сповіщень

Пізніше ми згенеруємо справжнє сповіщення про зміну конфігурації пристрою для тесту сповіщень, тому тут ми використовуємо політику "зміни конфігурації пристрою" як приклад. Переконайтеся, що для масиву, який використовується для тесту сповіщень, позначено «Зміна конфігурації пристрою», а тип сповіщень вказано за допомогою SNMP.



 

3. Рівень сповіщень

Створюючи новий пристрій для тесту оповіщення, ми генеруємо сповіщення «Конфігурація пристрою змінилася». Оповіщення знаходиться на інформаційному рівні, тому ми повинні переконатися, що синя піктограма обрана принаймні для тесту оповіщення.


 

4. Увімкнення журналу налагодження storevntd та журналу INFO Unisphere

 Змініть наступні параметри у файлі SE daemon_options:

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

Збережіть файл, як описано в кроці 1; Ми повинні перезапустити фонову службу storeVNTD,
а потім перезапустити службу SMAS. Після перезапуску служби smas змініть рівень журналювання Unisphere на INFO. (Примітка. Перезапуск служби smas повертає рівень журналювання до типового значення, тобто WARN. )
 

5. Тест на оповіщення

Згенеруйте справжнє сповіщення, використовуйте tcpdump для захоплення пакунка SNMP і перевірте журнал налагодження storevntd . 

1. Запустіть команду tcpdump на сервері Unisphere, щоб підготуватися до захоплення пакетів SNMP:

tcpdump -i any udp port 162 

2. Виконайте наступну команду, щоб перевірити існуючий лічильник подій SNMP:

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. Створіть 100M LUN в Unisphere. Перевірте панель сповіщень Unisphere, і ви побачите, що згенеровано сповіщення «Конфігурація пристрою змінилася». Якщо ви не бачите спливаючого вікна, натисніть кнопку «Оновити» на верхній панелі сторінки Unisphere.

 (Якщо ви також увімкнули політику стану пристрою, ви також можете побачити сповіщення "Стан пристрою змінено на Онлайн").


 

4. Перевірте вихідні дані tcpdump.

Наведене нижче свідчить про те, що сповіщення SNMP успішно перехоплено:
 

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. Перевірте лічильник подій ще раз. Ми бачимо ще одну подію snmp.

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. Перевірте журнал налагодження storenvtd :

Якщо ви можете знайти такі записи в журналі, це означає, що storevntd успішно доставив сповіщення 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

Наведені вище докази свідчать про те, що оповіщення SNMP було успішно розіслано з боку Unisphere. Якщо нам не вдасться захопити пакет SNMP за допомогою tcpdump і storevntd також не має доказів успішної доставки подій, зберіть emcgrab і залучіть технічну підтримку.