2022-07-25 snmptrap のパケットを tcpdump でキャプチャする

<!-----

Yay, no errors, warnings, or alerts!

Conversion time: 0.363 seconds.


Using this Markdown file:

1. Paste this output into your source file.
2. See the notes and action items below regarding this conversion run.
3. Check the rendered output (headings, lists, code blocks, tables) for proper
   formatting and use a linkchecker before you publish this page.

Conversion notes:

* Docs to Markdown version 1.0β33
* Fri Jul 29 2022 01:48:50 GMT-0700 (PDT)
* Source doc: 2022-07-25 snmptrap のパケットを tcpdump でキャプチャする
* This is a partial selection. Check to make sure intra-doc links work.
* Tables are currently converted to HTML tables.
----->

## 想定するユースケースとメリット

監視設定を行う際において、snmptrap の動作確認を行いたくなる時があります。

わざとネットワークスイッチのケーブルを抜いて SNMPTRAP を発行し、監視サーバで検知するかどうかを確認するなどです。

この時、想定に反して監視サーバで検知されなかった場合はトラブルシューティングを行うことになりますが、監視アプリケーションそのもの、監視サーバと監視対象間のネットワーク、監視対象機器そのもの、監視設定、 SNMPTRAP 設定、などなど確認する点がたくさん生じます。

監視アプリケーションをホストするサーバ側で tcpdump を実行し、 snmptrap が本当にインターフェースに届いているかを確認することで、問題をかなり切り分けることができます。


## 環境



* CentOS7
* tcpdump version 4.9.2

```
tcpdump --version
tcpdump version 4.9.2
libpcap version 1.5.3
OpenSSL 1.0.2k-fips  26 Jan 2017
```



なお、IPアドレス、 MAC アドレスについては実際の出力をドキュメント用のものに置き換えています。


## ローカルホストでの疎通を確認

以下のように tcpdump を発行した状態で、別セッションを開いて snmptrap をコマンドから発行します。

インターフェースは「lo」を指定します。

「-XX」や「-vv」を入力することで、より詳細な情報を得ることができます。


```
tcpdump --direction in --number -i lo port 162
```


今回は warmstart の trap を発行します。


```
[root@localhost ~]# snmptrap -v1 -c public 127.0.0.1 0 127.0.0.1 1 0 '' .1.3.6.1.6.3.1.1.5.2 s .1.3.6.1.6.3.1.1.5.2
```


tcpdump を実行しているセッションにおいて、 snmptrap のパケットの情報が表示されました。


```
[root@localhost ~]# tcpdump --direction in --number -i lo port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
    1  17:20:45.634565 IP localhost.35251 > localhost.snmptrap:  Trap(58)  .0.0 127.0.0.1 warmStart 28274072 S:1.1.5.2=".1.3.6.1.6.3.1.1.5.2"
^C
1 packet captured
2 packets received by filter
0 packets dropped by kernel
```



## 監視サーバと監視対象間での疎通を確認

今度は、監視サーバ側で tcpdump を実行し、監視対象機器から snmptrap を発行します。

インターフェースについては、外部トラフィックを受け付けるインターフェースを指定します。今回の監視サーバであれば「eth0」となります。


```
tcpdump --direction in --number -i eth0 port 162
```


今回は監視対象サーバも CentOS7 ですので、 snmptrap コマンドで warmstart の SNMPTRAP を送信します。


```
snmptrap -v1 -c public 192.0.2.186 0 192.0.2.58 1 0 '' .1.3.6.1.6.3.1.1.5.2 s .1.3.6.1.6.3.1.1.5.2
```


監視対象サーバのアドレス (192.0.2.58) から、 162番のポートにトラフィックが来た事がわかりました。


```
[root@localhost ~]# tcpdump --direction in --number -i eth0 port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    1  17:26:34.611003 IP 192.0.2.58.59894 > 192.0.2.186.snmptrap:  Trap(58)  .0.0 192.0.2.58 warmStart 216829747 S:1.1.5.2=".1.3.6.1.6.3.1.1.5.2"
```



### 他の方法

今までは「162番ポート」という条件でトラフィックをフィルタリングしていましたが、送信元 IP アドレスで絞ることも一つの方法です。

この場合、 snmptrap 受信以外のトラフィックについても確認することができます。


```
[root@localhost ~]# tcpdump -S -i eth0 host 192.0.2.58
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:38:36.535868 IP 192.0.2.58.55393 > 192.0.2.186.snmptrap:  Trap(58)  .0.0 192.0.2.58 warmStart 216901939 S:1.1.5.2=".1.3.6.1.6.3.1.1.5.2"
17:38:54.458072 IP 192.0.2.58 > 192.0.2.186: ICMP echo request, id 46870, seq 1, length 64
17:38:54.458144 IP 192.0.2.186 > 192.0.2.58: ICMP echo reply, id 46870, seq 1, length 64
17:38:59.471137 ARP, Request who-has 192.0.2.58 tell 192.0.2.186, length 28
17:38:59.472433 ARP, Reply 192.0.2.58 is-at 00:00:5e:00:53:01 (oui Unknown), length 28
```



## Ref

[Testing SNMP packets are being sent out an interface on Netbackup Appliances](https://www.veritas.com/support/en_US/article.100009877)