• tcpdumpを使ったトラブルシューティング例

 
 
Print Friendly, PDF & Email

はじめに

Arista EOSは、オープンなLinux上で動作しており、Linuxが持っている便利なツールをEOS上で利用することが可能です。
今回の記事では、tcpdumpを使ったトラブルシューティングの例についてご説明します。

EOS上でtcpdumpを実行すると、装置のコントロールプレーンに出入りするトラフィックのみが表示されます。これには、スイッチを通過するデータプレーントラフィック(ユーザのトラフィック)は含まれません。

 

トラブルの例

2台のルータ間でBGPセッションの確立ができないというトラブルをtcpdumpを使ってトラブルシューティングする、というケースを例にして説明します

 

環境

各ルータは、レイヤ2のイーサネットサービスを通じて接続されており、BGPを使った経路の交換が行われています。

問題の把握と原因追求

ある日、Router1とRouter3のBGPの接続が出来ないというトラブルが発生しました。

運用担当者の調査の結果、以下のことがわかりました。
1) Router1からRouter2へのPINGはOK、BGPネイバーステータスはEstablishで正常
2) Router1からRouter3へPINGが飛ばない。ARP未解決。BGPネイバーステータスはIdleで何らかの異常
3) 全てのルータのインタフェースリンク ステータスは正常
4) レイヤ2イーサネットサービスでも、特に異常は無いとの報告

運用担当者は、調査結果からレイヤ2イーサネットサービスに何らかの問題があると想定。
また、Router1とRouter3の間でARP解決が出来ていないということで、Router1のEOS上でtcpdumpを使って、再度Router1からRouter3へのPING試験を実施することにしました。

ICMPとARPのみフィルタリングし、BGPなどの他のパケットはtcpdumpしません。

 

tcpdumpを使った調査

1)Router1へSSHアクセス
(2セッションの接続、PING用:SSH1 / tcpdump用:SSH2)
運用PCからRouter1へ2セッションのSSHアクセスをします。

 

2)Router1(SSH2)でVLAN10を対象にしたTCPDUMPを実行

Router1#bash tcpdump -nevvi vlan10 icmp or arp
tcpdump: listening on vlan10, link-type EN10MB (Ethernet), capture size 262144 bytes

※VLAN10のICMPとARPパケットのみtcpdumpを実施

 

3)Router1(SSH1)から、Router2へPINGを3回実行

Router1#ping 192.168.0.2 repeat 3 interval 3
PING 192.168.0.2 (192.168.0.2) 72(100) bytes of data.
80 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=33.5 ms
80 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=33.9 ms
80 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=32.6 ms

--- 192.168.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6005ms
rtt min/avg/max/mdev = 32.657/33.391/33.970/0.567 ms

PINGが実行されると、SSH2の画面では以下のようなICMPのやりとりが表示されます。

07:03:12.451800 11:22:33:44:55:66 > 22:33:44:55:66:77, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 64, id 9259, offset 0, flags [none], proto ICMP (1), length 100)
192.168.0.1 > 192.168.0.2: ICMP echo request, id 19064, seq 1, length 80
07:03:12.485328 22:33:44:55:66:77 > 11:22:33:44:55:66, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 64, id 65047, offset 0, flags [none], proto ICMP (1), length 100)
192.168.0.2 > 192.168.0.1: ICMP echo reply, id 19064, seq 1, length 80
07:03:15.454283 11:22:33:44:55:66 > 22:33:44:55:66:77, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 64, id 9727, offset 0, flags [none], proto ICMP (1), length 100)
192.168.0.1 > 192.168.0.2: ICMP echo request, id 19064, seq 2, length 80
07:03:15.488234 22:33:44:55:66:77 > 11:22:33:44:55:66, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 64, id 65090, offset 0, flags [none], proto ICMP (1), length 100)
192.168.0.2 > 192.168.0.1: ICMP echo reply, id 19064, seq 2, length 80
07:03:18.457365 11:22:33:44:55:66 > 22:33:44:55:66:77, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 64, id 9873, offset 0, flags [none], proto ICMP (1), length 100)
192.168.0.1 > 192.168.0.2: ICMP echo request, id 19064, seq 3, length 80
07:03:18.490007 22:33:44:55:66:77 > 11:22:33:44:55:66, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 64, id 21, offset 0, flags [none], proto ICMP (1), length 100)
192.168.0.2 > 192.168.0.1: ICMP echo reply, id 19064, seq 3, length 80

6 packets captured
6 packets received by filter
0 packets dropped by kernel

結果から、Router1とRouter2の間では、既にARPの解決が出来ており、通信も正常であると判断できます。

 

4)Router1(SSH2)で、VLAN20を対象にしたtcpdumpを実行

Router1#bash tcpdump -nevvi vlan20 icmp or arp
tcpdump: listening on vlan20, link-type EN10MB (Ethernet), capture size 262144 bytes

※VLAN20のICMPとARPパケットのみtcpdumpを実施

 

5)Router1(SSH1)から、Router3へPINGを3回実行

Router1#ping ip 192.168.0.3 interval 2 repeat 3
PING 192.168.0.3 (192.168.0.3) 72(100) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable

--- 192.168.0.3 ping statistics ---
2 packets transmitted, 0 received, +1 errors, 100% packet loss, time 5998ms

PINGでの表示は、1回目のリクエストはタイムアウト。
2回目から「Host Unreachable:目的の端末からのARP応答が無い/端末が無い」としてICMPのメッセージで通知されました。

SSH1からPINGが実行されると、SSH2の画面では以下のようなやりとりが表示されます。
通常、ARP解決されていない端末にPINGを実行する場合、まず対象のARPを解決してからICMPパケットを投げるという動作になります。
その際、ARPパケットを1つのARPリクエストに対して、相手側へ3回ARPパケットを送ります。
Router3のARP解決をするために、ARPブロードキャストパケットをRouter1から送出していますが、Router3からのARPリプライが無いことがわかりました。

※今回の例では、ARPリクエストに対してリプライがないので、リトライした結果3パケット出ていることがわかります。

01:12:18.892831 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28
01:12:19.890283 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28
01:12:20.890298 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28

01:12:21.892831 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28
01:12:22.890283 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28
01:12:23.890298 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28

01:12:24.892831 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28
01:12:25.890283 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28
01:12:26.890298 11:22:33:44:55:66 > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell 192.168.0.1, length 28

調査結果からの考察と対処

tcpdumpを使った追加の調査結果から、レイヤ2イーサネット側に何か問題が発生していると想定し、再度ネットワークサービス事業者に調査を依頼したところ、サービス内の装置のMACアドレステーブルに異常があり、装置を再起動することでRouter1とRouter3の間の疎通が正常化しBGPセッションも正常になりました。

 

まとめ

今回のtcpdumpを使ったトラブルシューティングの例では、ARPとICMPのみのご紹介でしたが、tcpdumpのフィルタオプションを変えることで、BGPやOSPF、STPなどのコントロールパケットも全てキャプチャすることが可能です。
お客様によっては、現在のコロナ渦において、すぐに現地で調査することが難しい状況も十分にありえます。
リモート環境からでも、コントロール系のパケットを装置に負荷を掛けずにキャプチャできることは、トラブル発生時の原因調査に置いて非常に強力なツールとなることは間違いありません。

また、今回はコントロールパケットをtcpdumpする例でしたが、アリスタの製品ではAdvanced Mirroringを使えば、データプレーンでやりとりされるパケットもtcpdumpすることも可能になります。次回はこちらについてご説明します。

 

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: