接続先のL2スイッチが「ファイルバックする」の設定でvSwichが「ファイルバックしない」設定だった場合、通信が切れることってありますか？

[shidox]

ざっくりした質問でたいへん申し訳ありません。

NICチーミングに関して教えてください。

*****************************************
ロードバランシング：IPハッシュに基づいたルート
ネットワークのファイルオーバー検出：リンク状態のみ
スイッチの通知：はい
ファイルバック：いいえ

*****************************************

以上の設定をした場合、接続先のL2スイッチが「ファイルバックする」の設定だった場合、ポートの通信ができなくなる事ってありますでしょうか？

現在VMkernelポートの通信が突然きれる事象が発生していて問題の切り分けをしているところです。

アドバイスをいただけたら幸いです。

[gowatana]

こんにちは。

「VMkernelポートの通信が突然きれる事象」ですが、

具体的には、どの程度の期間の通信断が発生していますでしょうか？

また、通信断の発生後は、何か復旧作業などは実施していますでしょうか？

[shidox]

ありがとうございます。助けてください・・・。

ハードウエアのオンボードNICが１～４あり、拡張ボードNIC5～8があるのですが、すべての物理ポートにケーブルをさすと通信ができなくなります。
しかしオンボードか拡張ボードのどちらかのみを使用すると復旧してつながるようになります。
なので、現在はオンボードのみケーブルをさしていて片肺で動かしている状態です。

esxi側の設定(vmKernel)は【0番：オンボード側】【4番：拡張側ボード側】に設定しています。
現状、ハードの問題では無いところまで切り分けできています。

仮定としてフェールバックを無効にしているのが良くないのかなと思っていますがあまり怪しくはなさそうですね。

かんかVM側の設定でアップリンクが切り替わるような動きなどあるのでしょうか？

[shidox]

オンボードNICが１～４あり、拡張ボードNIC5～8 でNCIが８つあるのですが、オンボードNICが１～４がオートネゴシエーションが無効になっていて、NIC5～8はオートネゴシエーションが有効になっていました。　これってとてもいけないことでしょうか？

[gowatana · Accepted solution]

こんにちは。

下記については、vmnic0 と vmnic4 を指していますでしょうか？

esxi側の設定(vmKernel)は【0番：オンボード側】【4番：拡張側ボード側】に設定しています。

フェイルバックの「はい / いいえ」の設定も関係しているかもしれませんが、

まずは下記を確認してみるとよいと思います。

• vmnic0 ～ vmnic7と、物理NIC1～物理NIC8 の対応が意図している通りか確認する。
  （ケーブルの抜き差しやMACアドレスなどで）
• 物理NIC1（オンボード） と 物理NIC5（拡張NIC）を、どちらかだけ接続して、通信断が発生するか確認する。
  （どちらかの経路だけで発生する問題かもしれないので切り分けのため）
• 物理スイッチ側の設定も、意図した通りか確認する。
  （ESXiの物理NICがリンクアップしたとしても、それより上位の経路で問題が発生しているかもしれないため）

オートネゴシエーションの設定方針については一般的には揃えると思いますが、

まずは下記のKBを確認されることをお勧めします。

ESXi/ESX ホストのネットワーク アダプタの速度およびデュプレックスの構成 (1004089)

https://kb.vmware.com/s/article/1004089?lang=ja 

https://kb.vmware.com/s/article/1004089  （原文）

また、ご利用のサーバのベンダからの推奨設定などもあるので、

サーバベンダの提供するESXiインストールに関するドキュメントも併せて確認することをお勧めします。

あと用語についてですが、正しくは下記になります。

ファイルバック → フェイルバック

[shidox]

gowatanaさん。ありがとうございます。

仮想スイッチのフェイルバックやオートネゴシエーションの設定はあまり関係なかったようです。

gowatanaさんからいただいたアドバイスを参考にしてネットワークの問題切り分けをおこなっていますが、どうも物理スイッチの動作がおかしいようです。

クライアント端末や特定のサーバからpingの疎通がとれたりとれなかったりします。　しかも突然発生します。

もうすこし調査してみます。

[shidox]

web client 6.7 で仮想スイッチの設定でディフォルトでロードバランシングの設定にオーバライドで「送信元の仮想ポートの基づいたルート」の設定が入っていたせいでした。

この設定値によって、hostクライアントの仮想スイッチのチーミングで設定した「IPハッシュに基づいたルート」の設定値が無効になってしまい、ポートが不正な動作をしていた

様です。

今回の”ロードバランシングの設定にオーバライドで「送信元の仮想ポートの基づいたルート」の設定が入ってしまう”ことはweb client 6.7の既知のバグなのでしょうか？

オーバライドを設定する場所もとてもわかりづらく、この原因に気がつくまでとても時間がかかりたいへんでした。

でも結局解決できたので良かったです。

ありがとうございました。