☰

VLan および VSphere マシンとの接続が失われる

tag-icon • tag-icon networking vmware-vsphere vlan local-area-network vmware-esx
VLan および VSphere マシンとの接続が失われる

vSphere セットアップ上のいくつかの仮想マシンで非常に奇妙な状況に直面しており、何が起こっているのかよくわかりません。

もともと、私はが DHCP サーバー、がゲートウェイ、が私のワークステーション (DHCP サーバーから IP を取得)、が同僚のワークステーションである192.168.9.0/24ネットワークで作業しています。 これは問題なく動作し、そのネットワーク上のすべてのマシンは他のマシンと連携でき、すべてのマシンが互いに ping を実行でき、ゲートウェイ経由で世界中に ping を実行できます。192.168.9.254192.168.9.43192.168.9.82192.168.9.15

VSphere 6.5 クラスターがインストールされており、それぞれ192.168.9.1、、192.168.9.2および192.168.9.3静的アドレスを持つ 3 つのホストがあります。これらのマシンは ESXi バージョン 6.0.0、3380124 を実行しており、それぞれ 4 つの NIC がスタックされた 1 組の Dell N1524 スイッチに接続されており、これらのスイッチは192.168.9.0/24ネットワークに接続されています。そのクラスターには、Production各ホストの NIC に結び付けられたネットワークがあり、VM は192.168.9.254DHCP から IP を取得します。これも問題なく動作しますが、VM の使用が増加したため、DHCP サーバーによって提供される IP 範囲が非常に混雑し、午後に到着すると一部の一般ユーザーが IP アドレスを取得できないほどになっています。

これを回避するために、各ホストの vSwitch に新しいポート グループを追加し、それらのポート グループに同じ名前 ( VLAN) と同じ VLAN 値 (42)を与えました
。Dell の物理スイッチは、ホストの NIC が接続されているポート (トランク モード) のデフォルトの VLAN とともにその VLAN を許可するように再構成されました。この VLAN をネットワークにして、10.10.10.0/24通常のネットワークから簡単に認識できるようにしたので、スイッチ10.10.10.252にその VLAN の静的 IP を与えました。

Production次に、2 つのインターフェイス(192.168.9.110 に 1 つ、 に 1 つVLAN)を持つ Windows 2012 仮想マシンを作成し、RRAS ロールをアクティブ化して、このマシンがとその他の世界との10.10.10.254間のゲートウェイとして機能するようにしました。静的アドレスを 持つ のインターフェイスが 1 つだけある 2 つ目の Windows 2012 仮想マシンを作成し、 と名付けました。ドメイン コントローラー、DHCP、および DNS ロールをアクティブ化しました。DHCP は範囲内のリースを提供し、DNS はネットワークから DNS に転送するだけです。10.10.10.0/24
VLAN10.10.10.253MDC10.10.10.50 - 10.10.10.200192.168.9.0/24

次に、2 つの仮想マシンを作成しました。1 つは最初のホストに MDC と Gateway と一緒に、もう 1 つは 3 番目のホストに単独で作成し、両方ともネットワークに接続しました。接続は正常に機能しているように見えたので、次の PowerCLI コマンドを使用して、既存の VM をフォルダーからネットワークにVLAN移動することにしました。TemporaryVLAN

Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -NetworkName VLAN

vmxnet3また、このコマンドですべてのネットワークアダプタが正しいことを確認しました。

Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -Type vmxnet3

接続はまだ正常だったので、ネットワークに接続された別の仮想マシン群を作成しVLAN、3 つのホストすべてに配置しました。これにより、次のトポロジが得られます。

ホスト1
MDC ( 10.10.10.253)
ゲートウェイ ( 10.10.10.254– 192.168.9.110)
マシン1_H1 ( 10.10.10.64)
マシン2_H1 ( 10.10.10.57)

ホスト2
マシン3_H2 ( 10.10.10.65)

ホスト3
マシン4_H3 ( 10.10.10.50)
マシン5_H3 ( 10.10.10.51)

そして、ネットワーク接続に関しては、内部VLANと外部への接続の両方で非常に奇妙な結果が得られます。

  • MDCはスイッチ以外の全員にpingを送信できます（10.10.10.252）
  • ゲートウェイはMachine5_H3以外の全員にpingを送信できる
  • Machine1_H1はMachine3_H2以外の全員にpingを送信できる
  • Machine2_H1はスイッチ以外のすべてにpingを送信できます（10.10.10.252）
  • Machine3_H2はホスト1とMachine1_H1を除くすべてのホストにpingを送信できます。
  • Machine4_H3 は を除くすべてのマシンに ping を送信できます192.168.9.43(192.168.9.15名前google.fr解決は OK)
  • Machine5_H3は192.168.9.254、192.168.9.82（自分のワークステーション）を除くすべてのマシンにpingを実行できます。10.10.10.254
  • 私のコンピュータ ( 192.168.9.82) は、Machine5_H3 ( 10.10.10.51)以外のすべてのコンピュータに ping を送信できます。

これらのテストを行う前に、すべてのマシンでファイアウォールがオフになっていることを確認しました。また、arp -aMDC を実行して、MAC アドレスの競合や重複がないかどうかを確認しました。Temporary念のため、フォルダー内のマシンもすべてオフにしましたが、上記の結果に変化はありませんでした。念のため、次のスニペットを使用して、これらのマシンの新しい MAC アドレスを強制的に生成しました。

foreach ($VM in (Get-Folder Temporary | Get-VM))
{
  $NetworkAdapter = $VM | Get-NetworkAdapter
  $NetworkAdapter | Set-NetworkAdapter -MacAddress 00:50:56:1a:ff:ff -Confirm:$false
  $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
  $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
  $spec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
  $spec.deviceChange[0].operation = "edit"
  $spec.deviceChange[0].device = $NetworkAdapter.ExtensionData
  $spec.deviceChange[0].device.addressType = "generated"
  $spec.deviceChange[0].device.macAddress = $null
  $VM.ExtensionData.ReconfigVM_Task($spec)
}

状況は何も変わりませんでした。

次に、ゲートウェイに Wireshark をインストールし、トラフィックの監視を開始して10.10.10.254、そのマシンが関係するすべてのトラフィックを確認できるようになりました。たとえば、私のワークステーション ( 192.168.9.82) が Machine5_H3 ( ) から ping される10.10.10.51と、PING 要求が表示され、次に PING 応答が表示されますが、それでも Machine5_H3 は応答を受信しなかったと報告します。逆にすると、192.168.9.82ゲートウェイからの要求は表示されますが、応答は表示されません。

したがって、どこかでいくつかのパケットがドロップされていると私は信じています。主な容疑者はスイッチ ( 10.10.10.252) ですが、この理論を確認するために何ができるかわかりません。

リンク アグリゲーションは元々 DELL スイッチ スタックで有効になっていましたが、ワークステーションからネットワーク内に IP を持つ VM への接続に問題が発生したため192.168.9.0/24、無効にしました。
ただし、スイッチ スタックでこの設定を変更しても、上記の状況は変わりませんでした。

何か間違ったことをしたか、設定の詳細を見落としたに違いありませんが、それが何なのかわかりません。この謎を解決するのに役立つ提案があればいただければ幸いです。

答え1

Zac67 のコメントに従って、3 つのホストすべてで NIC チーミング構成を確認したところ、最初の 2 つのホストでは「IP ハッシュに基づくルート」パラメータが使用されており、3 番目のホストでは「発信元仮想ポートに基づくルート」が使用されていたことがわかりました。

次に、3 番目のホストを他のホストと同じ値に設定し、最初のオプションに関連付けられた「リンク アグリゲーションは物理スイッチで設定する必要があります」という警告を読み取ります。

そこでスイッチに戻り、適切なポートのリンク アグリゲーションを再度有効にしましたが、接続全体が不安定になり、192.168.9.0/24ネットワーク内のマシンは部分的にアクセス不能になりましたが、ネットワーク内のマシンには何の変化もありませんでした10.10.10.0/24。

そこで、逆の方法を採用し、スイッチのリンク アグリゲーションを無効にし、3 つのホストすべてで「発信元仮想ポートに基づくルート」オプションを使用することにしました。

これにより、ネットワークの正常な動作が戻り192.168.9.0/24、ネットワークの接続性が向上しました10.10.10.0/24。改善されたというのは、一部のマシンがまだアクセス不能だったためです。つまり、Host3DHCP サーバーにアクセスできず、IP を取得できないマシンです。Wireshark
を使用してトラフィックを観察すると、ARP ブロードキャストがフィルタリングされる場合があることがわかりました。これにより、一部のマシンが互いに通信できない理由が説明されましたが、解決策の手がかりはまだ得られませんでした。

答えが見つかる望みもなく数週間この問題に悩まされた後、私たちは最初にインフラストラクチャのインストールを支援したコンサルタントを招き、彼らから次の 2 つのことを聞きました。

  1. LACPはVLANと互換性がありません
  2. VLAN 42はスイッチのポートの1つで禁止されていました

したがって、構成で LACP がまったく使用されないようにし、ポートの制限を削除することで、完全に機能する状況を実現できました。

さて、スイッチ上の 1 つのポートだけで VLAN 42 を禁止する方法をどうやって実現したのか疑問に思います。

LACP と VLAN の非互換性については、これが問題の原因になるとは思ってもみませんでした。しかし、彼らからそのことを聞かされて、どうやら DELL スイッチをスタックする場合によく知られている問題のようですが、この件に関して明確な答えは見つかりませんでした。しかし、それがなくても動作するので、私にとってはまったく問題ありません。

関連情報