VMware ESXi 仮想スイッチのreverse teamingについて

VMware ESXi の仮想スイッチの挙動に関して同僚に質問され調べたことがあったので、軽くまとめておく。

TL;DR

前提

注意

この記事の内容はESXi 6.7に対して確認しており、それ以外については確認していない。

NICチーミングについて

詳細はドキュメントにあるので、概要についてのみ記述する。

仮想マシンがESXi外部と通信するために、ESXiの仮想スイッチに対してESXiホストが持つNICを割り当てる必要がある。（仮想スイッチのアップリンクと呼ばれる。） 冗長化や負荷分散のために複数のNICをこのアップリンクとして指定することができ、これをNICチーミングという。

イメージとしてはリンクアグリゲーションが近いし、実際に対向となるスイッチでLAGの設定をしなければならない構成もあるが、LAGを設定しないでも、NICチーミングを利用できる方法も用意されている。 チーミングでは複数NICにどのように通信を分散させるかを規定したロードバランシングポリシーを選択でき、送信元の仮想マシン（正確には仮想スイッチのポート）ごとに利用する物理NICを決定したり、送信元MACアドレスから決定する方法などを選択した場合は、対向スイッチでLAGを設定する必要がない。 （むしろ、設定してはいけない。）

reverse teaming

以前トラブルシューティング時に存在に気づいたが、あまり言及されるのをみないreverse teamingと呼ばれるらしい機能が仮想スイッチには存在している。これはどうやら前述のNICチーミングにおいてLAGを必要としないケースで動作するもののようだ。

スイッチにLAGが設定されなければ、BUMトラフィックについてはフラッディングするため、仮想スイッチの複数のアップリンクに複製された同一のフレームが到達することとなる。したがって、宛先MACアドレスから転送先の仮想マシンを単純に決定するだけでは、複製されたフレームを仮想マシンが受け取ることとなる。それを防ぐため、上述のロードバランシングポリシーが選択されている場合は、仮想マシンがフレーム送信時に利用しているアップリンクで受け取ったパケットしか仮想マシンに転送しないようフィルタリングがなされる。これがreverse teamingと呼ばれるものである。

送信時に利用しているアップリンクの対向ポートにて、仮想マシンのMACアドレスが学習されているはずなので、仮想マシン宛のユニキャスト通信は送信時に利用しているアップリンクで受け取ることになるという想定で、そのような作りになっているのだと思われる。

この機能自体はよく考えられているが、細かい部分でトラブルシューティング時などに影響してくるので、気をつける必要もある。

ESXiでのパケットキャプチャ時の注意

ESXiでは pktcap-uw コマンドによりパケットキャプチャが可能で、アップリンクや仮想マシンが接続される仮想スイッチのポートなどを指定してキャプチャを取得できる。 この時、キャプチャポイントを --capture オプションにより指定できるが、この指定によってreverse teamingが作用した後の結果が取れるかそうでないかが変わってくるようだ。

具体的には、 --capture PortOutput では、reverse teamingが働く前の結果が取得される。 仮想スイッチのポートを指定してキャプチャした際、特にキャプチャポイントを --capture で指定しなかった場合は、デフォルトでこの状態になると思われる。 明示的に --capture VnicRx を指定した場合は、reverse teamingを反映した結果となる。

promiscuous mode と reverse teaming

promiscuous mode

通常仮想スイッチはMACアドレスの学習はしないものの、仮想マシンに割り当てているMACアドレスを元に仮想マシンを特定し、仮想スイッチが受け取ったパケットの転送を行う。（イメージとしては、MACテーブルに静的にエントリが指定されており、動的な変更がないような状態での動きに近いかもしれない。）そのため、同一ポートグループを利用していたとしても他の仮想マシンへのユニキャスト通信を受け取ることは基本的に無い。

しかし、promiscuous mode(無差別モード)が有効な場合は、そのポートグループ内の全仮想マシンにパケットが転送される。（イメージとしては、ハブの動作に近いかもしれない。）仮想マシンがL2VPNの終端になっている場合や、再仮想化などの都合で、仮想NICに割り当てられているアドレス以外のアドレスを受け取る必要がある場合などに、よく利用される。

ただし、ESXi6.7からは分散仮想スイッチにてMACアドレス学習させるオプションが出来ているので、必要性は薄れているかもしれない。

reverse teaming の影響

検証したところでは、promiscuous modeであるかどうかに関わらず、reverse teamingは同じように動作するらしい。 しかしこの事がかえって複雑な挙動につながることがある。

promiscuous modeでは、そのポートグループ上で仮想マシンがやり取りした通信は、同一ポートグループ上の他の仮想マシンにも見えてしまうことがある。 同一ESXiホスト上であればポートグループ内の全仮想マシンに転送するため、それ自体は自然なことである。

しかしもう少し詳しく見ると、他の仮想マシンの通信が見えたり見えなかったりの条件が非常に複雑であることがわかる。

ESXiホストを跨ぐ場合はそれらを結ぶ物理スイッチの挙動にも依存するが、通常は物理スイッチ側はpromiscuous modeのような動作はしないだろうから、送信元と宛先のどちらも自身と同じホスト上の仮想マシンではないユニキャスト通信は、フラッディングされない限り基本的に見ることが出来ない。 これは、仮想スイッチの挙動以前に物理スイッチがESXiまで転送してこないので当然の話ではある。 同一ホスト上の仮想マシンが送信元である通信については、（promiscuous有効の同一ポートグループを利用している時）自身が宛先でなくとも転送されてくるため見ることが出来る。

ややこしいのは、以上に当てはまらない、同一ホスト上の仮想マシンが宛先で、送信元がホスト外であるような通信についてである。 基本的にはpromiscuous modeの動作にしたがい、通信を見ることが出来るはずなのだが、この場合もreverse teamingは健在であるため、この通信を受け取るアップリンクが自身が送信時に利用するものでないと、破棄されてしまい見ることが出来ない。 例えばロードバランシングポリシーが送信元ポートによるものであれば、アップリンクの割り当ては仮想マシンの再起動などでも変化することがあるぐらいなので、同じホスト上の別仮想マシンへの通信は見えたり見えなかったりする…というのが実情になる。

送信元 送信先 見えるかどうか
同じホスト上の仮想マシン 同じホスト上の仮想マシン 見える
同じホスト上の仮想マシン ホスト外 見える
ホスト外 同じホスト上の仮想マシン アップリンクが同じ時だけ見える
ホスト外 ホスト外 見えない

例えば、ある仮想マシンへの通信を別の仮想マシンでキャプチャするために、promiscuous modeが利用できるのではないかと考えた場合は、このような事情も加味しないといけないので気をつけなければならない。

検証の記録

構成

手順と結果