如何疑難排解 SNMP 目標未收到從 Unisphere 傳送的 SNMP 警示。

以下為四個位置，可檢查 SNMP 目標是否無法接收從 Unisphere 傳送的 SNMP 警示。
 

• 客戶 SNMP 目標的社群字詞應與 Unisphere 的預設社群字 （SNMP_trap） 相符。  
• 客戶必須確保 Unisphere 伺服器與 SNMP 目標之間的網路連線良好。我們可以在 Unisphere 伺服器上使用 opensl 和 tracepath 命令來驗證連線能力，並在 Unisphere 伺服器上使用 tcpdump 命令在警示測試期間擷取 SNMP 套件。要證明 Unisphere 能成功傳送 SNMP 警示，一個直接的方式就是讓 SNMP 目標直接連線至 Unisphere 伺服器。如果直接連線的 SNMP 目標可收到 SNMP 警示，而非直接連線則無法接收，這表示問題出在客戶的網路上。  
• Unisphere SNMP 警示設定應全部正確設定，其中包括：    
• SNMP 通知組態、警示原則設定、通知層級。

 
如果上述情況沒有問題，支援人員必須繼續進行警示測試，並啟用 SE storevntd 偵錯記錄、 Smas INFO 記錄集，以及擷取 tcpdump 。如果看不到已成功傳送 SNMP 警示的證據，請收集 emcgrab 並測試結果。
請注意，在測試期間，最好產生實際警示，而非使用「TEST SNMP」功能，因為與實際警示相比，「TEST SNMP」套裝小巧且較不可靠，可為 UDP 套件傳輸。

 

疑難排解的詳細步驟： 

1. SNMP 社群文字。

預設社群字稱為「SNMP_trap」。如果與 SNMP 目標的社群字詞不符，我們可以在 SE daemon_options檔案中新增下列行來變更：
 

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

儲存檔案，然後重新開機 storevntd 精靈，讓變更生效。（由於不可靠，請勿使用重載命令）

stordaemon shutdown storevntd
stordaemon start storevntd

重新開機 storenvtd 後，先前從 Unisphere 警示組態頁面載入的警示原則也會遺失。為了讓警示原則重載並在 storevntd中註冊，我們也必須重新開機 SMAS 服務。
（以下命令用於在 Linux 伺服器中重新開機 SMAS 服務。您可以追蹤SNMP 事件並未傳送至嵌入式 U4V 或 SNMP 伺服器，以重新開機內嵌 Unisphere的 SMAS服務。

在 Unisphere 伺服器上，cd至路徑 /etc/init.d，然後執行下列命令：

./smas stop
./smas start

然後我們可以使用以下命令來檢查 storevntd 事件註冊狀態。（SMAS 重新開機後，事件會在storevntd中註冊，這需要一點時間）

stordaemon action storevntd -cmd list -regs –v

 

2. 網路連線能力。

我們可以在 Unisphere 伺服器上使用 opensl 和 tracepath 命令來檢查 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 區塊上的「Configure」字，並確定已設定正確的 SNMP 目標 IP 和埠。

（注意：使用單一 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. 警示原則設定

稍後，我們將會針對警示測試產生真正的裝置組態變更警示，因此在此使用「裝置組態變更」原則作為範例。請確定已針對用於警示測試的陣列檢查「Device Config Change」，且通知類型是以 SNMP 指定。



 

3. 通知等級

透過建立新裝置進行警示測試，我們產生的警示即為「裝置組態已變更」。警示處於資訊層級，因此至少必須確定已選取藍色圖示以進行警示測試。


 

4. 啟用 storevntd 偵錯記錄和 Unisphere INFO 記錄

 在 SE daemon_options檔案中變更下列參數：

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

依步驟 1 儲存檔案;我們必須重新開機storevntd精靈，然後重新開機SMAS服務。
SMAS服務重新開機後，請將 Unisphere 的記錄層級變更為資訊。(注意：重新開機 SMAS 服務會將記錄層級變更為預設值，也就是警告。)
 

5. 警示測試

產生真正的警示，使用 tcpdump 擷取 SNMP 套件，並檢查 storevntd 偵錯記錄。 

1. 在 Unisphere 伺服器上執行 tcpdump 命令，以準備好摻取 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. 在 Unisphere 中建立 100M LUN。檢查 Unisphere 警示面板，您會看到系統會產生「裝置組態已變更」警示。如果您無法看到警示彈出，請按一下 Unisphere 頁面頂端列上的重新整理按鈕。

 （如果您也啟用了「裝置狀態」原則，您也會看到「Device state has changed to Online」（裝置狀態已變更為線上） 警示已產生）。


 

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

以上證據顯示已從 Unisphere 端成功傳送 SNMP 警示。如果我們無法使用 tcpdump 擷取 SNMP 套裝，且 storevntd 也沒有成功交付事件的證據，請收集 emcgrab並聯絡技術支援部門。