SNMP Trapが届かない原因は?送信キューを変更して検証

UDPで送信されるため途中で失われたのか、経路が収束する前に送信されたのか・・・。
 
今回はCisco ISRを例に、SNMP Trapが送信されない原因とチューニング方法について解説します。
 

Trapが届かない理由はUDPだけではない


SNMP Trapには受信確認の仕組みがありません。 そのため、送信後に通信経路で失われても、機器はサーバーに届いたかどうかを判断できません。
 
しかし、その手前にもう一つ確認すべき場所があります。
それは送信キュー。
 
Cisco機器は通知先ごとにTrapの送信キューを持ちます。
イベントが集中してキューに収まりきらなければ、Trapは送信前に破棄されます。
 
で設定するキューのデフォルト値は10です。
注意:SNMP Trapの送信キューの初期値や設定方法は、Cisco機器の機種、OS、バージョンによって異なる場合があります。本記事はCisco ISR(IOS XE 16.10.01b)での検証結果です。他の機器に適用する際は、対象機器の公式資料と実機の表示を確認してください。
 
実機では「show snmp」コマンドで確認可能です。
になっているので、キューサイズが10ということが分かります。 ※の0側の数値はを実行した時点でキューに残っている件数です
また、 は送信された数、 が送信前に破棄された数です。
 
💡
「20件発生したら、キューサイズ10では必ず10件破棄される」という意味ではありません。 キューは送信処理と並行して空くため、破棄数はイベントの発生間隔や機器の処理状況によって変わります。
 
スポンサード

検証環境と手順


項目内容
機器Cisco ISR
OSCisco IOS XE Software, Version 16.10.01b
Trap受信サーバー
イベントの発生方法誤ったコミュニティ名でSNMP Getを同時に20件実行
Trap受信数の確認サーバーでUDP 162番ポートをで取得
イベント(SNMP Trap)を同時に複数発生させるため、同時にSNMP Getを行うPythonスクリプトを作成しました。 SNMP認証エラーを発生させるため、あえてコミュニティ名を変更してGetしています。
 
また、サーバーでTrap受信数確認のため、次のコマンドを実行しています。 受信数は「Recv: xx」の形式で表示されます。
 
1回目はキューサイズがデフォルトの10、2回目は30に変更してから、同じ20件の認証エラーを発生させました。
 
図1:検証環境の構成

検証1回目:キューサイズ10


通知先の表示にはが記録され、サーバー側の受信数は10件でした。

検証2回目:キューサイズ30


Cisco機器でキューサイズを30に変更しました。
は、キューに保持できるTrapの最大件数を変更するコマンドです。
再び20件の認証エラーを発生させると、サーバー側で20件のTrapを受信しました。
機器側の通知先表示はでした。
 
20→30にキューサイズを変更したことで、20件のTrapが破棄されずに送信されました。
 
図2:今回の検証結果。キューサイズ30では、サーバーで20件すべてを受信しました。
 

おわりに


Trapが受信できないときは、サーバー側の受信状況に加え、機器側のも確認してみてください。
のカウンター値(dropped等)は今までの合計値になるので、前回からの差分を見る場合は、定期的にコマンドを実行して状態を記録しておくのが良いかもしれません。 
 
また、NW機器を導入する際の検証では、SNMP Trapの検証は簡易的に行うことも多いと思います。 (サーバーで最低1件Trap受信できていればOKとか)
最大でどの程度のTrapが同時に発生する可能性があるかを、設計段階で見積もっておくことが大切です。
根本的な対策として、不要なTrapを送信せず、必要な通知だけに絞ることも重要です。
また、送信対象とするTrapについては、設計段階で運用担当者と認識を合わせておきましょう。
 

 
その他記事