【実機検証】SNMP TrapとInformの違いをWiresharkで比較！応答と再送動作を確認してみた

はじめに

SNMP（Simple Network Management Protocol）には、ネットワーク機器から監視サーバへイベントを通知する仕組みとして、TrapとInformRequestがあります。

どちらも障害やインターフェースの状態変化などを通知するために使用されますが、大きな違いは「受信確認応答があるかどうか」です。

Trap：通知を送信するが、受信確認応答は要求しない
Inform：通知を送信し、受信側からのResponseを要求する

では、Informの受信側が応答しなかった場合、実際にはどのような通信が発生するのでしょうか。

今回はCisco C1812JとRaspberry Piを使用して、TrapとInformを送信し、Wiresharkでパケットを比較しました。

さらに、Raspberry Pi側のSNMP通知受信デーモンを停止し、InformRequestの再送動作も検証しました。

検証環境

使用機器

機器・ソフトウェア	用途
Cisco C1812J	SNMP通知の送信元
Raspberry Pi	SNMP通知の受信先
snmptrapd	Trap・Informの受信
tcpdump	パケットキャプチャ
Wireshark	パケット解析

Cisco C1812JのIOSは以下のバージョンです。

Cisco IOS Software, C181X Software
Version 12.4(15)T8

System image file is
"flash:c181x-advipservicesk9-mz.124-15.T8.bin"

ネットワーク構成

+--------------------------+
| Cisco C1812J             |
|                          |
| IP: 192.168.20.1         |
| SNMP通知送信元           |
+------------+-------------+
             |
             | LANケーブル直結
             |
+------------+-------------+
| Raspberry Pi             |
|                          |
| IP: 192.168.20.2         |
| snmptrapd / tcpdump      |
+--------------------------+

SNMPバージョンはv2cを使用し、検証用コミュニティ文字列をPublic01としました。

TrapとInformの通知先にはUDP/162を使用します。

TrapとInformの違い

Trapとは

Trapは、SNMPエージェントからSNMPマネージャへイベントを一方向に通知する仕組みです。

例えば、インターフェースがダウンした場合に、ネットワーク機器から監視サーバへ通知を送信できます。

Cisco C1812J              Raspberry Pi
     |                         |
     |-------- Trap ---------->|
     |                         |
     |     Responseなし        |
     |                         |

TrapにはSNMPプロトコル上の受信確認応答がありません。

そのため、送信元は通知が受信側で正常に処理されたかどうかをTrapのResponseで確認することはできません。

InformRequestとは

InformRequestは、SNMPv2で導入された通知方式です。

Trapと異なり、受信側からのResponseを要求します。

Cisco C1812J              Raspberry Pi
     |                         |
     |---- InformRequest ----->|
     |                         |
     |<------ Response --------|
     |                         |

InformRequestを受信したSNMPマネージャは、正常に処理できればResponse-PDUを返します。

応答が得られない場合、送信元は設定されたタイムアウトや再送回数に従って再送できます。

ただし、Responseがあることは通知プロトコル上の受信確認を意味するものであり、監視システム側の後続処理まで完了したことを保証するものではありません。

TrapとInformの比較

項目	Trap	Inform
通知方式	一方向	応答確認あり
受信確認Response	なし	あり
SNMPによる再送制御	なし	あり
通信量	比較的少ない	応答・再送分が増える
主な用途	一般的なイベント通知	受信確認が必要な通知

Raspberry Pi側の受信設定

まず、Raspberry PiにSNMP通知受信デーモンであるsnmptrapdをインストールします。

sudo apt update
sudo apt install -y snmptrapd

次に、検証用の設定ファイルを作成します。

echo 'authCommunity log Public01' | sudo tee /tmp/snmptrapd-lab.conf

authCommunity log Public01は、コミュニティ文字列Public01を使用する通知のログ出力を許可する設定です。

既存のsnmptrapdサービスが起動している場合は停止します。

sudo systemctl stop snmptrapd

UDP/162を使用しているプロセスがないか確認します。

sudo ss -lunp | grep ':162'

待ち受けプロセスがないことを確認したら、snmptrapdを起動します。

sudo snmptrapd -f -Lo -n -C -c /tmp/snmptrapd-lab.conf udp:162

これで、Raspberry Pi側でTrapとInformを受信する準備ができました。

パケットキャプチャ

別のターミナルでtcpdumpを起動します。

sudo tcpdump -i eth0 -nn -s 0 -w snmp-notifications.pcap 'udp port 162'

この状態でCiscoから通知を送信し、Wiresharkで解析します。

Trapの送信検証

Cisco側の設定

Cisco C1812JでTrapの送信先を設定します。

configure terminal
snmp-server host 192.168.20.2 traps version 2c Public01
snmp-server enable traps snmp linkup linkdown
end

通知先はRaspberry Piの192.168.20.2です。

また、インターフェースのリンク状態変化に関する通知を有効化しています。

Trapの発生

今回は検証用のVlan30を使用し、インターフェースの状態を変更して通知を発生させました。

configure terminal
interface Vlan30
 shutdown
end

※ インターフェースの状態変更は、通信への影響がない検証用インターフェースで実施してください。リンク状態によってはshutdownだけでは通知が発生しない場合もあります。

Wiresharkで確認

Raspberry Pi側でパケットをキャプチャした結果、SNMP Trapが1パケット送信されていることを確認できました。

192.168.20.1 → 192.168.20.2
SNMPv2-Trap
UDP/162

Trapに対してSNMP Responseを返す仕組みはありません。

この点が、次に検証するInformRequestとの大きな違いです。

InformRequestの送信検証

続いて、Cisco側の通知方式をTrapからInformに変更します。

Cisco側の設定

既存のTrap送信先設定を削除します。

configure terminal
no snmp-server host 192.168.20.2 traps version 2c Public01

Informの送信先を設定します。

snmp-server host 192.168.20.2 informs version 2c Public01
end

リンク状態変化の通知設定はそのまま使用します。

Informの発生

Trapの検証と同じように、Vlan30の状態を変更して通知イベントを発生させました。

Wiresharkで確認

キャプチャを確認すると、以下の通信が観測されました。

192.168.20.1 → 192.168.20.2
InformRequest

192.168.20.2 → 192.168.20.1
GetResponse

Trapとは異なり、Raspberry PiからCiscoへResponseが返っています。

ここでWiresharkのSNMP詳細を確認すると、InformRequestとResponseのrequest-idが一致していました。

request-idはSNMP要求と応答を対応付けるための識別子です。

この結果から、Raspberry PiがInformRequestを受信し、それに対応するResponseを返していることを確認できました。

なお、Wireshark上ではInformへの応答がget-responseと表示されますが、これは正常な動作です。

InformRequestの再送動作を検証

ここからが今回の検証で特に興味深かった部分です。

InformRequestは、受信側から応答が返らなかった場合に再送できる仕組みを持っています。

そこで、Raspberry Pi側のsnmptrapdを停止し、Responseが返らない状態を作ってみました。

Raspberry Pi側でsnmptrapdを停止

sudo systemctl stop snmptrapd

手動起動している場合は、実行中のターミナルでCtrl+Cを押して停止します。

UDP/162の待ち受けがなくなっていることを確認します。

sudo ss -lunp | grep ':162'

その後、tcpdumpだけを起動します。

sudo tcpdump -i eth0 -nn -s 0 -w inform-retry.pcap 'host 192.168.20.1 and udp port 162'

この状態でCisco側からInformを発生させます。

キャプチャ結果

Wiresharkで確認したところ、InformRequestが合計4パケット送信されていました。

各パケットの送信間隔は以下のとおりです。

No.	request-id	前回送信からの間隔
1	23	初回
2	24	約2秒
3	25	約4秒
4	26	約8秒

送信間隔は約2秒、4秒、8秒と倍増していました。

これは、指数バックオフ（Exponential Backoff）に似た動作です。

今回のCisco C1812Jでは、応答が得られない状況で、送信間隔を段階的に延ばす挙動が観測されました。

ただし、この動作がすべてのCisco IOSやSNMP実装で共通とは限りません。

request-idが変化していた

再送検証でもう1つ興味深かったのが、request-idの変化です。

今回観測された4パケットのrequest-idは次のとおりでした。

同じ要求の再送ではrequest-idを維持する動作が一般的に想定されますが、今回のキャプチャでは連番になっていました。

そこで、4パケットが同じ通知イベントに関係しているかを確認するため、WiresharkでVariable Bindingsを比較しました。

sysUpTime.0の比較

sysUpTime.0のOIDは以下です。

1.3.6.1.2.1.1.3.0

この値は、通常、SNMPエージェントの管理機能が初期化されてからの経過時間を示します。

確認したところ、4パケットすべてでsysUpTime.0が一致していました。

snmpTrapOID.0の比較

続いて、通知の種類を表すsnmpTrapOID.0も確認しました。

1.3.6.1.6.3.1.1.4.1.0

こちらも、4パケットすべてで同じ値でした。

考察

今回の結果をまとめると、以下のようになります。

項目	観測結果
InformRequestの送信数	4パケット
Response	なし
送信間隔	約2秒 → 4秒 → 8秒
request-id	23 → 24 → 25 → 26
sysUpTime.0	全パケットで一致
snmpTrapOID.0	全パケットで一致

送信間隔が倍増していることに加え、sysUpTime.0とsnmpTrapOID.0が一致していることから、同一イベントに対する再送動作である可能性が非常に高いと考えられます。

ただし、すべてのVariable Bindingsの一致までは確認していないため、完全に同一の通知内容だったと断定することは避けます。

今回の環境では、request-idが変化しながら、同一イベントと考えられるInformRequestが繰り返し送信される挙動が観測されました。

TrapとInformの比較結果

今回の実機検証をまとめると、以下のとおりです。

比較項目	Trap	Inform
通知の送信	成功	成功
受信確認Response	なし	あり
正常時の通信	Trap	InformRequest → Response
request-idによる応答対応付け	不要	一致を確認
受信側停止時の再送	未検証	複数回の送信を確認
観測した送信間隔	—	約2秒・4秒・8秒

Trapは通知を送信するだけのシンプルな仕組みです。

一方、InformはResponseを使用して受信確認を行い、応答がない場合には再送する仕組みを備えています。

ただし、Informであっても、再送回数の上限に達した場合や通信障害が継続する場合には、通知が受信されない可能性があります。

そのため、Informは通知の信頼性を高める仕組みではありますが、確実な配送を無条件に保証するものではありません。

まとめ

今回はCisco C1812JとRaspberry Piを使用して、SNMP TrapとInformRequestの違いを実機で検証しました。

結果として、以下のことが確認できました。

Trapは一方向の通知であり、SNMP Responseを要求しない。
InformRequestは受信側からResponseが返る。
InformRequestとResponseのrequest-idが一致し、要求と応答を対応付けられた。
受信側を停止すると、InformRequestが4パケット観測された。
InformRequestの送信間隔は約2秒、4秒、8秒と倍増していた。
InformRequestの再送と考えられるパケットではrequest-idが変化していたが、sysUpTime.0とsnmpTrapOID.0は一致していた。

今回の検証を通して、TrapとInformの違いを単なる仕様の比較ではなく、実際のパケットの動きとして確認できました。

特にInformRequestの再送動作では、送信間隔やrequest-idの変化など、実機ならではの興味深い結果が得られました。

次回は、SNMPv3で誤った認証鍵を指定した場合にどのような通信が発生するのかを、Wiresharkで確認してみたいと思います。

はじめに

検証環境

使用機器

ネットワーク構成

TrapとInformの違い

Trapとは

InformRequestとは

TrapとInformの比較

Raspberry Pi側の受信設定

パケットキャプチャ

Trapの送信検証

Cisco側の設定

Trapの発生

Wiresharkで確認

InformRequestの送信検証

Cisco側の設定

Informの発生

Wiresharkで確認

InformRequestの再送動作を検証

Raspberry Pi側でsnmptrapdを停止

キャプチャ結果

request-idが変化していた

sysUpTime.0の比較

snmpTrapOID.0の比較

考察

TrapとInformの比較結果

まとめ

関連記事