単一 VTEP への ECMP：VXLAN のエントロピーはどこから来るのか

等コストマルチパスがホストルートには無意味だという主張は、真実に聞こえるほど繰り返されています。/32 は宛先アドレスを選ぶのであって、その選択がパケットを一本の物理リンクに縛るわけではありません。宛先がリモートの VXLAN トンネル端点であれば、複数のネクストホップが異なるオーバーレイフローを運べます。運ぶかどうかは、転送ハッシュに何を見せてよいかで決まります。残りは外側ヘッダー上の算術であり、プレフィックスの性質ではありません。

経路が到達性を決め、ハッシュが分散を決めます。

俗説：/32 は一本の経路を意味する

OSPF が VTEP ループバックへの等コスト到達性を報告しても、転送テーブルは同じプレフィックスに対してネクストホップのグループをインストールします。プロトコルは候補を提供し、プラットフォームがそのうちどれを使えるか、パケットをどう割り当てるかを決めます。各カプセル化フレームごとに新しいハッシュを計算するルーティングプロトコルはありません。この分離があるからこそ、同じ経路を持つ二台のルーターがトラフィックを違う形で分散できます。

ルート表示だけでなく、インストールされた転送エントリを見てください。ハードウェアやポリシーの制限により、コントロールプレーンがまだ広告している候補が落ちることがあります。

エントロピーはどこから来る必要があるか

二台の VTEP の間では、外側の送信元アドレスと宛先アドレスは固定のままで、UDP 宛先ポートは一般的な配備では 4789 です。それらの値だけを読むハッシュは一定の入力を見て、一定の経路を返します。外側ヘッダーのどこかが変わる必要があり、それを変えられる装置が VTEP です。

RFC 7348 は、カプセル化フレーム内のフィールドから UDP 送信元ポートを導出することを提案しています。すると内部の会話が異なれば外側のタプルも異なり、通常の転送ハッシュに扱える材料が与えられます。

転送ハードウェアがパケットのより深部まで見られるなら、そのハッシュ実装がどの内部フィールドをサポートするかを確認してください。その深さをすべてのアンダーレイ装置の要件とみなすべきではありません。送信元ポートの変化だけでも有用な差異はすでに現れます。

実際に得られるハッシュを確認する

仮定せずに測定してください。カプセル化トラフィックのサンプルを取得して外側の送信元ポートを見て、その結果を転送エントリやリンクごとのカウンターと比較します。

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

一つの送信元ポートが多くの異なる内部会話に現れるなら、VTEP はそのフィールドを変化させておらず、アンダーレイをどう調整しても負荷は分散しません。逆に多数の異なるポートがあり、ネクストホップが一つだけ使われているなら、転送グループ側の問題です。

サンプルの前後でカウンターを記録し、アップリンクを共有する無関係なトラフィックにも注意してください。そうしないと数値はハッシュの実際より悪く見えます。

均等な分散が意味しないこと

フロー単位のハッシュは、入力と利用可能な経路集合が変わらない限り、一つの会話を一本の経路に保つように設計されています。したがって一本の大きな TCP 転送がすべてのアップリンクを束ねることはなく、リンクを追加してもそのフローは速くなりません。これは正常な動作であり、故障ではありません。

複数のフローが偶然に同じネクストホップで衝突することもあります。短いサンプルは大きく偏って見えることがありますが、ハッシュは設定どおりに動いているのです。またリンク障害や経路集合の変化は、転送の途中で既存のフローを移すことがあります。

承認された計画のもとで代表的なアドレスペア、トランスポート、レートで試験し、リンクアグリゲーションのメンバー選択とルーティングされたマルチパスの選択は分けて考えてください。二段のハッシュが独自のパターンを作るからです。ネクストホップグループが埋まっていることと外側エントロピーが見えることが結果を説明します。プレフィックス長ではありません。