Je ne suis pas entièrement convaincu que ma solution est correcte, mais je peux au moins éclairer un peu plus ce qui se passe.
Contexte
Linux a en fait plusieurs tables de routage, et elles sont recherchées une par une dans un ordre de priorité spécifique jusqu'à ce qu'une table avec une route correspondante soit trouvée. Vous pouvez éventuellement rechercher certaines des tables de routage en fonction de l'adresse source ou du protocole ; voir le ip-rule(8) page de manuel.
Le problème est la table de routage "locale", qui a la priorité 0, la plus élevée possible. La table "locale" est remplie automatiquement par le noyau et contient l'interface "évidente" et les routes de diffusion. Pour IPv6 sous Linux, cela inclut apparemment l'intégralité du bloc de multidiffusion.
Le problème
Je vais utiliser le iproute2 outil plutôt que le plus traditionnel route , car il me montrera tout ce que j'ai besoin de savoir.
Sur ma machine 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
... Et mes paquets multicast pour ff15 ::1 (5 ==site-local,> lien-local) se retrouvent sur eth0, car la table de routage "locale" correspond en premier et remplace la table "principale", même si le La table "main" a une route plus spécifique. Ce comportement prioritaire est correct dans le schéma plus large de routage de stratégie, mais le choix d'ajouter automatiquement ff00 ::/8 à la table locale est discutable pour moi.
Ma solution
Je n'ai pas assez d'expérience pour savoir si c'est une bonne idée, mais :
# ip -6 route add ff15::/16 dev eth1 table local
et maintenant mes paquets ff15 ::1 sont acheminés via eth1.
Cela correspond quelque peu à la sémantique de la table locale, en ce sens qu'elle est acheminée directement via un périphérique. Cela ne semble pas tout à fait correct (compte tenu de la gestion automatique et "vous ne devriez pas avoir à regarder ce tableau"), mais c'est la meilleure solution que j'ai trouvée.