エンドポイントは接続され、ポートも有効なのに、監視ホストからは到達できません。誰かが反対側からpingを実行すると動き始めるため、問題は断続的に見え、ファブリックは無実に見えます。このパターンは静かなホストの特徴です。送信がまれなので、接続状態よりもファブリックの探索と更新の挙動のほうが重要になります。対象のIP、MAC、ブリッジドメインを一つ決めて、次の解決のやり取りを追ってください。

次のARPまたはNDのやり取りを追う

IPv4では要求元ホストのARPのやり取りを観察します。IPv6ではNeighbor SolicitationとAdvertisementを追います。要求が意図したローカルセグメントと意図したVNIに入ることを確認してください。正しいブリッジドメインに決して届かない要求には、どのプロキシも応答できません。

次に、ファブリックがターゲットについて何を知っているかを見ます。MACのみのルートはLayer 2の宛先を識別できますが、プロキシにはまだそのIP-to-MACバインディングがありません。これは別々のレコードであり、片方を確認してももう片方のことは何も分かりません。

有効なバインディングがあれば、プロキシはポリシーに従って応答できます。ただし、そのバインディング内のMACには依然として有効な転送経路が必要です。バインディングがない場合、何かが応答から学ぶ前に、要求はフラッディングまたはレプリケーションの経路を通ってエンドポイントの接続に届かなければなりません。

一致しなければならない二つのレコード

MACルートはEthernetアドレスがどこにあるかに答えます。プロキシテーブルはどのIPがどのMACに対応するかに答えます。最近通信していないホストは、完全に正常なMACルートを持ちながら使用可能なプロキシエントリを持たないことがあり、それがまさに健全な接続で解決の失敗を生む状態です。

リモート側の接続で、エンドポイントが実際にやり取りを受け取り応答しているかを確認します。その応答はローカルの学習と対応するEVPN広告を更新します。手動のpingが問題を直したように見えるのは、ファブリックが待っていたトラフィックをあなたが生成したからです。修正が続かない理由も同じです。更新されたエントリが期限切れになれば、エンドポイントは再び沈黙します。定期的なpingは症状を扱い、設計上の隙間を隠します。

応答の後は、選択されたルートとインストールされた転送状態を要求元へ向かって逆にたどります。解決の成功と転送の成功は別々の出来事であり、これを混同するチケットはあなたを誤った層へ送ります。

標準が実際に前提としていること

RFC 9161 は、動的なプロキシ学習と、未知のARPおよびND要求の既定のフラッディングについて述べています。そのフラッディングの完全な抑制は、学習やプロビジョニングの前提がそれを安全にする展開に限られ、多くの設定ガイドが示唆するよりも狭い条件です。

新しく検出されたエンドポイントを期待するファブリックには、それらの要求に対する動作する経路が必要です。BUMトラフィックを減らすために未知の要求のフラッディングを無効にしたなら、静かなホストがその代償を払う集団であり、症状は数週間後に断続的な到達性の苦情として現れます。

抑制設定は、ファブリックが何を知ると約束しているかという表明として読んでください。バインディングを供給するものが何もなければ、その約束はまれな送信者には当てはまりません。設定された抑制と、それを供給すべきプロビジョニングシステムを比較してください。両者が食い違うとき、ファブリックは設定どおりに動作しており、直すべきは期待のほうです。

更新、エージング、そして静的という選択肢

標準は、動的エントリが期限切れになる前の、サポートされた更新プローブについて述べています。応答は関連するブリッジとプロキシの状態を更新し、応答がない場合は削除とルートの撤回に正当につながることがあります。これはすべてのタイマーを延ばして抑え込むべき不具合ではありません。

エージングタイマーを無期限に延ばすことは、目に見える障害を古い障害と交換します。ファブリックはホストが去った場所を広告し続けます。実装の文書化された制御を使い、エンドポイントが話すと合理的に期待できる頻度に合った寿命を選んでください。

既知の管理されたエンドポイントには、静的またはコントローラがプロビジョニングするバインディングが正当な第二のモデルです。交換と移動を扱う所有者が必要です。ホストが別のポートへ移っても、プロビジョニングされたレコードは自動では更新されないからです。

次のチケットの前に記録すること

バインディングの出所、最後の更新時刻、現在の場所、撤回イベントをMACルートのそばに残してください。その記録は、チケットが本当に問うていることに答えます。アプリケーションは探索を待っているのか、古い状態に頼っているのか、解決に成功した後に転送できていないのか。

次に、三つのうちどれを運用するかを決めます。フラッディングを伴う探索、現実的な寿命での更新、所有者を伴うプロビジョニングは、いずれも擁護できます。一方のために設定され、もう一方のように振る舞うことを期待されるファブリックこそ、静かなホストが消える場所です。

関連記事