ESXiでのパケットキャプチャでハマったこと

仕事でちょっと障害があってESXiでパケットキャプチャを取る機会がありました。その際にハマったことを紹介いたします。

「ESXi上のVMでネットワーク通信が突然できなくなる場合がある」というものです。整理すると次の通りです。

VM利用者からは通信できてないので「なんとかせい！」となり、仮想基盤やVM（ゲストOS）での調査や対応を行いました。

まずは手探りで下記を実施しました。

これで回復した場合もありましたが、しばらくして再発したりもして、VM利用者の温度感がかなり上がってしまいました。

何とかしなければと頭をひねり、同じポートグループのVM間の通信については、同じESXiにVMを収容 してみたところ、VM間の通信は回復しました。

これにより、ESXiのアップリンクを出てネットワーク機器にトラフィックが流れると通信できない場合がある とわかりました（ネットワーク機器が事象の原因である可能性が高いとの仮説）。

事象発生しているVM（ゲストOS）でtcpdumpを取ってみたところ、ARPのリクエストは出しているがリプライがない ことがわかりました。

また、ARPリクエストを投げないように、ゲストOSで スタティックMACの設定 （このIPのMACアドレスはこれですって設定）を入れると、VM間通信もゲートウェイへの通信もできることを確認できました。

これで、ARP解決ができていないことが原因であるとわかりました。

同じESXiに2台のVMを配置してVM間通信だと問題なく出来るようになるということは

ということになります。

であれば「ネットワーク機器が事象の原因である可能性が高いのではないか？」とネットワーク担当に申し上げました。

ネットワーク担当者から「VMから出ているARPリクエストがESXiのアップリンクからも出ているかを確認してほしい」となりました。

そこで、ESXiでパケットキャプチャすることになりました。

pktcap-uw コマンドを使いました。

障害が起きた環境のESXiは2本の10Gbpsのアップリンクがあります（vmnic0, vmnic1）。

事象発生しているVM（ゲストOS）でデフォルトゲートウェイアドレスにpingを打ちながら、ESXiのアップリンクの1本ずつ順番にパケットキャプチャを取りました。

pktcap-uw --outfile vmnic0.cap --uplink vmnic0
pktcap-uw --outfile vmnic1.cap --uplink vmnic1

あれ？どちらのキャプチャファイルにもゲストOSから出ているARPリクエストが見当たらない！！！これだと、ネットワーク機器の不具合というよりは ESXiのソフトウェア的な不具合の可能性が高くなるのか？ ということで、当初立てた仮説と違う結果に頭が混乱しました。

そこで、基本に立ち返り、pktcap-uwコマンドの使い方が間違って可能性 を疑って下記を調べてみました。

dir オプションというのがあり、デフォルトが受信トラフィックしかキャプチャされない とのことでした！今回特に確認したいのは 送信トラフィック だろ！

そもそも 何でデフォルトが受信トラフィックのみなんだろうか？ とは思いつつ、dirオプションで 双方向トラフィックを指定してパケットキャプチャをし直しました。

pktcap-uw --outfile vmnic0.cap --dir 2 --uplink vmnic0
pktcap-uw --outfile vmnic1.cap --dir 2 --uplink vmnic1

ということで、vminc1の経路が怪しそうだということがわかりました。

これで、事象の原因がネットワーク起因の可能性が高くなったので、ネットワーク担当の方の調査に移行しました。 ESXiのvmnic1の上位スイッチでのパケットキャプチャを何か所かでやってもらう予定です。

本事象はまだ解決してはおらず、対応中です。 「ハマったら基本に立ち戻る」 というのは、やはり大事であると再認識しました。

解決したら続編を書きたいと思います。

※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。

VMwareユーザ会（VMUG）に興味のある方は、

から入会していただけると幸いです。イベントでお会いできるのを楽しみにしております。

以上です。