vMotion時のRARPフレームを ESXiのpktcap-uwで観測する


概要

vSphereクラスタ環境で仮想マシンをvMotionで移行した際に発行されるRARP（Reverse Address Resolution Protocol）フレームを、ESXi標準のパケットキャプチャコマンド pktcap-uw を使って観測する。移行先ESXiの物理アップリンク（vmnic0 / vmnic1）でキャプチャを取得し、実際に流れるRARPフレームの中身を確認する

RARPが発行される意味

vMotionによってVMがホストを移行すると、物理スイッチから見れば「あるMACアドレスが接続されているポート」が突然変わることになる。スイッチのMACアドレステーブル（CAM / TCAM）はこの変化をすぐには認識できないため、テーブルが更新されるまでの間はVM宛のフレームが旧ホスト側のポートへ送られ、フレームがロストしてしまう。

これを防ぐため、vMotionの際には移行先ESXiが、VMが使用しているMACアドレスの接続先が変わったことをスイッチへ知らせる仕組みを持っている。その通知に使われるのがRARPフレームだ。スイッチはこのフレームを受け取ることで、該当MACアドレスのポートマッピングを即座に更新できる。

補足：GARPではなくRARPvSphere仮想スイッチはGARP（Gratuitous ARP）ではなく、EtherType 0x8035 のRARPパケットを送出する。これはARPリクエストの一種で、ESXiが上流スイッチに対してMAC-to-switchportマッピングの更新を「アナウンス」するために用いられる。

ESXiがRARPを発行する主なケース

参考KBによれば、「Notify Switch」オプションが「yes」に設定されている前提で、ESXiホストは次のような場面でRARPを送出する。

  1. リンクのダウン／アップ時 — VMが別のアップリンク経由で接続し直す必要がある場合、稼働中のリンクからRARPが送られる。VMごとに約5個（最大8個）。リンクフラップ時は状態変化ごとに最大8個。短時間に多数のイベントが起きると、ホストが送出数を制限したり一部を送らない場合もある（LAGには適用されない）。
  2. vMotion後 — 移行先ESXiが、移行先で接続されたVMのためにRARPを送出する（通常1秒未満）。もしvMotion後にVMが接続を失う場合、上流スイッチがそのMACを学習できていないか、接続先ネットワークアダプタのVLAN構成を確認する。
  3. vCenterがESXiを再接続したとき — vCenterやvpxdの手動再起動などで、ポートグループ・分散スイッチ（vDS）・ポートが以前接続していたシステムに再適用される際。※標準仮想スイッチ（vSS）はESXiが管理するため対象外。
  4. 分散スイッチのポートグループ/チーミング変更時 — 変更が以前接続していたシステム向けにESXiへ再適用される際。※IPv6使用VMの場合、「Notify Switch」がyesでもIPv6 Neighbor Solicitationは送出されない。
  5. アップリンク単位への最適化 — 不要なフラッディングを避けるため、ブロードキャストドメイン内の全vNICポートではなくアップリンクからのみRARPを送出する最適化が導入された。vSphere 8.0では com.vmware.port.extraConfig.forward.rarp オプションで特定のswitchportにもRARPを受信させる挙動変更が可能。

検証環境

検証には3ノード構成のvSphereクラスタを使用する。移行する仮想マシンは3つのvNICを持ち、それぞれ別のポートグループに接続されている。3つのvNICは物理アップリンク vmnic0 / vmnic1 のいずれかに紐づく。

vNICMACアドレス接続先アップリンク
vNIC100:50:56:b3:31:b3vmnic1
vNIC200:50:56:b3:7e:9dvmnic1
vNIC300:50:56:b3:75:98vmnic0

図1：移行対象VMのvNICと物理アップリンクの対応。vNIC1・vNIC2は vmnic1 に、vNIC3 は vmnic0 に接続される。

この構成のため、移行先ESXiの vmnic0 と vmnic1 の両方でキャプチャを取れば、3つすべてのvNICから発行されるRARPを観測できる。


図2：検証環境と観測のイメージ。移行先ESXi（esxi3）で、vNIC1・vNIC2 は vmnic1、vNIC3 は vmnic0 に紐づく。両アップリンクの送信フレーム（UplinkSndKernel）を pktcap-uw でキャプチャし、vMotion完了直後に各vNICのMACから送出されるRARP（0x8035）を観測する。

キャプチャコマンド（物理ポートでキャプチャする）

アップリンクを流れる送信フレームをキャプチャするため、キャプチャポイントに UplinkSndKernel を指定し、EtherTypeフィルタで 0x8035（RARP）に絞り込む。

# vmnic0 でキャプチャ
pktcap-uw \
  --uplink vmnic0 \
  --capture UplinkSndKernel \
  --ethtype 0x8035

# vmnic1 でキャプチャ
pktcap-uw \
  --uplink vmnic1 \
  --capture UplinkSndKernel \
  --ethtype 0x8035

キャプチャ例（移行先ESXiで実施）

移行先ホスト sb-e560f-esxi3 でvMotion実行時にキャプチャを取得すると、各vNICのMACアドレスを送信元とするRARPフレームが観測できる。
※下記に記載のキャプチャは全体の一部であり、実際には複数のRARPフレームが確認できる

vmnic 0 側（vNIC3 / 00:50:56:b3:75:98）

[root@sb-e560f-esxi3:~] pktcap-uw \
  --uplink vmnic0 --capture UplinkSndKernel --ethtype 0x8035

The name of the uplink is vmnic0.
The session capture point is UplinkSndKernel.
The session filter Ethernet type is 0x8035.
...
15:37:18.739084[1] Captured at UplinkSndKernel point, ... VLAN tag 83, ... length 60.
        Segment[0] ---- 60 bytes:
        0x0000:ffff ffff ffff 0050 56b3 7598 8035 0001
        0x0010:0800 0604 0003 0050 56b3 7598 0000 0000
        0x0020:0050 56b3 7598 0000 0000 0000 0000 0000
        0x0030:0000 0000 0000 0000 0000 0000

vmnic 1 側（vNIC1 / 00:50:56:b3:31:b3）

[root@sb-e560f-esxi3:~] pktcap-uw \
  --uplink vmnic1 --capture UplinkSndKernel --ethtype 0x8035
...
15:37:18.734345[1] Captured at UplinkSndKernel point, ... VLAN tag 81, ... length 60.
        Segment[0] ---- 60 bytes:
        0x0000:ffff ffff ffff 0050 56b3 31b3 8035 0001
        0x0010:0800 0604 0003 0050 56b3 31b3 0000 0000
        0x0020:0050 56b3 31b3 0000 0000 0000 0000 0000
        0x0030:0000 0000 0000 0000 0000 0000

～～中略～～

15:37:18.736696[5] Captured at UplinkSndKernel point, ... VLAN tag 82, ... length 60.
        Segment[0] ---- 60 bytes:
        0x0000:ffff ffff ffff 0050 56b3 7e9d 8035 0001
        0x0010:0800 0604 0003 0050 56b3 7e9d 0000 0000
        0x0020:0050 56b3 7e9d 0000 0000 0000 0000 0000
        0x0030:0000 0000 0000 0000 0000 0000

3つのvNIC（...75:98 / ...31:b3 / ...7e:9d）それぞれについて、それぞれのVLAN（tag 83 / 81 / 82）でRARPが送出されているのが確認できる。タイムスタンプもほぼ同時（15:37:18台）で、vMotion完了直後にまとめて発行されていることが分かる。

RARPフレームの中身をデコードする

vNIC3（00:50:56:b3:75:98）のフレームを例に、60バイトのペイロードを分解してみる。

バイト値意味
ff ff ff ff ff ff宛先MACブロードキャスト（全ポートへ通知）
00 50 56 b3 75 98送信元MACVMのvNIC3のMACアドレス
80 35EtherType0x8035 = RARP
00 01Hardware typeEthernet
08 00Protocol typeIPv4
06 / 04HW / Proto サイズMAC=6バイト / IP=4バイト
00 03Operation3 = RARP Request
00 50 56 b3 75 98Sender MACvNIC3のMACアドレス
00 00 00 00Sender IP0.0.0.0（IPは通知対象外）
00 50 56 b3 75 98Target MACvNIC3のMACアドレス
00 00 00 00Target IP0.0.0.0

■ 宛先（ブロードキャスト）　■ 送信元MAC　■ EtherType 0x8035

ポイントは、宛先がブロードキャスト、送信元がVMのMACアドレスであること。ESXiはVMになりすまして「このMACはこのポートから来る」とブロードキャストすることで、上流スイッチにポートの再学習を促している。IPアドレスは埋められていない（0.0.0.0）ため、これはあくまでL2レベルの通知である。

参考：ネスト環境で仮想マシン（ハイパーバイザー）が発行するRARPを観測する

ネスト構成でゲスト側のハイパーバイザーが発行するRARPを、仮想スイッチのポート側でキャプチャしたい場合の手順。まず対象VMが使用するポートIDを取得する（esxtop の n オプションでも確認可能）。

esxcli network vm list
esxcli network vm port list -w <World-ID>
# → 出力から PortID を確認する

取得したPortIDを指定し、vNICの送受信（VnicTx,VnicRx）でRARPをキャプチャする。

pktcap-uw \
  --switchport <PortID> \
  --capture VnicTx,VnicRx \
  --ethtype 0x8035

参考KB

IP to MAC mapping, GARP, RARP and Notify Switches — Broadcom Knowledge Base (Article 343401)

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

vSAN OSA更改時の考慮事項

  この投稿は、 vExperts Advent Calendar 2025 の 8 日目です。 文字ばかりですがご容赦ください     この記事の概要 VCF9 のリリースによって vSAN OSA の一部の Hybrid 構成が Deprecate になった。 そのため、 OSA 環境の更改においては ESA へのトランジションの検討が盛んになっている。 一方で、 ESA へのトランジションにおいては、 HCI のメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった 考慮事項も存在する。 本記事では、 vSAN クラスタの更改時によくある考慮事項を紹介する。   想定既存環境 以下のようなサンプル環境の更改を想定する   vSAN OSA クラスタ（ vSAN Ready Node 、クラスタ内の全ノードが更改対象） ライセンスはリテール版を利用し、 HW と更改時期がずれているため、更改対象ではない。 外部ストレージは無し TOR スイッチの HW 更改の対象に含める   ※ OEM ライセンス利用時や、 vSAN Ready Node より上位となる専用アプライアンスを利用している場合、 ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。   更改パターン   移行方法とストレージアーキテクチャをベースに大別すると以下の 4 パターンが考えられる。   OSA 玉突き更改 OSA 新規クラスタ ESA 新規クラスタ 分離型新規クラスタ（ vSAN MAX or 外部ストレージ）   更改パターンを選択する際の考慮事項を次項に列挙する     考慮ポイント 実績と安定性 OSA と外部ストレージ構成は実績や安定性の観点で申し分ない ESA も 2022 年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面では OSA や外部ストレージが勝る トラブルシューティングに関しても OSA/ ...
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む