私の解決策が正しいと完全に確信しているわけではありませんが、少なくとも何が起こっているのかをもう少し明らかにすることができます.
背景
Linuxには実際には複数のルーティングテーブルがあり、一致するルートを持つテーブルが見つかるまで、特定の優先順位で一度に1つずつ検索されます。オプションで、送信元アドレスまたはプロトコルに基づいてルーティング テーブルの一部を検索できます。 ip-rule(8) を参照してください
問題は、可能な限り最高の優先度 0 を持つ「ローカル」ルーティング テーブルです。 「ローカル」テーブルはカーネルによって自動的に入力され、「明白な」インターフェースとブロードキャスト ルートを保持します。 Linux での IPv6 の場合、これには明らかにマルチキャスト ブロック全体が含まれます。
問題
iproute2 を使用します 従来の route ではなくツール
Linux ボックス:
$ ip -6 route show table local
local ::1 via :: dev lo proto none metric 0
local fe80::213:a9ff:fe91:5bcb via :: dev lo proto none metric 0
local fe80::250:b6ff:fe44:37d1 via :: dev lo proto none metric 0
ff00::/8 dev eth0 metric 256
ff00::/8 dev eth1 metric 256
$ ip -6 route show table main
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
ff15::/16 dev eth1 metric 1024
ff00::/8 dev eth1 metric 1024
$ ip -6 rule show
0: from all lookup local
32766: from all lookup main
...そして、ff15::1 (5==site-local,>link-local) のマルチキャスト パケットは最終的に eth0 になります。 「メイン」テーブルには、より具体的なルートがあります。このオーバーライド動作は、ポリシー ルーティングのより大きなスキームでは正しいですが、ff00::/8 をローカル テーブルに自動追加するという選択には疑問があります。
私の解決策
これが良いアイデアかどうかを判断するのに十分な経験がありませんが、
# ip -6 route add ff15::/16 dev eth1 table local
これで、ff15::1 パケットが eth1 経由でルーティングされます。
これは、デバイスを介して直接ルーティングされるという点で、ローカル テーブルのセマンティクスと多少一致します。 (自動管理と「このテーブルを見る必要はない」ことを考えると) 正確には正しくありませんが、これが私が見つけた最良の解決策です。