ターゲット デバイスのイーサネット ケーブルをスイッチの別のポートに移動した後も、ping6 セッションは機能し続ける必要がありますか?

ターゲット デバイスのイーサネット ケーブルをスイッチの別のポートに移動した後も、ping6 セッションは機能し続ける必要がありますか?

これは本当に基本的な質問ですが、私の期待が間違っていないこと、そして私が見ているものが予期された動作ではないことを確認するために健全性チェックが必要です。

状況は次のとおりです。MacOS/X を実行している Mac Pro と、ARM ベースの Linux ボックスがあります。どちらも 8 ポートの Extreme Networks ギガビット スイッチに接続されています (インターネット アップリンクはなく、ローカル LAN のみです)。

私の Mac では、Linux ボックスに ping を送信する ping6 セッションを開始します。

$ ping6 fe80::21c:abff:fe00:55e5%en1

...そして予想通り、ポンというレスポンスが返ってきます。

次に、イーサネット スイッチに移動し、イーサネット スイッチから Linux ボックスに接続されているケーブルを外し、そのケーブルをイーサネット スイッチの別の開いているポートに再接続します。

この時点で、私の予想では、(数秒の一時停止の後)Mac 上の ping6 セッションが応答の確認を再開するはずです。

しかし、私の観察では、ping6 セッションが応答の受信を無期限に停止することがあります。少なくとも、Linux ボックスのイーサネット接続を元々接続されていたスイッチ ポートに戻すまで、応答の受信が停止します。(ping6 プロセスを停止して再起動しても効果はありません。さらに待っても効果はありません)

そこで私の主な質問は、私が観察している動作は予想される動作なのかということです。もしそうなら、このポート変更から回復するために(ソフトウェアで)何かできることはありますか?もしそうでないなら、何が間違っているのか何かお分かりですか?(私の疑いは、NDP の問題かもしれないということです)

答え1

ターゲット デバイスを別のスイッチ ポートに移動した後でも、ターゲット デバイスを再接続すると、ping 応答を受信し続ける必要があるのは正しいです。

ping6プロセスを停止して再起動しても効果はありません。さらに待っても効果はありません。

これは正常ではありません。ポート変更後、2 つのデバイス間で ping 要求または応答が送信されない原因が何かあります。Linux の具体的なファイアウォール構成の可能性についてはよく知りませんが、Windows マシンでは、ネットワーク インターフェイスを変更すると、異なるファイアウォール ルールが適用される場合があります。

スイッチ自体に問題がある可能性もありますが、Linux ボックスが新しいスイッチ ポートに接続されているときにネットワークと正常に通信できることを確認すれば、その可能性は簡単に排除できます。

答え2

ポートが変更されたマシンがトラフィックを送信するまで、スイッチはポートが変更されたことを知る方法がありません。イーサネット ケーブルを別のポートに移動したときに Linux マシンが静かでネットワーク アクティビティを行っていない場合は、トラフィックが送信されるまで待つ必要があります。

トラフィックを送信すると、スイッチはトラフィックが移動したことを認識し、内部テーブルを適切に更新します。

関連情報