Estou transpondo este exemplo do ipv4 para o ipv6.
O problema é que, a menos que você ativamente faça ping no ip de cada caixa com a fonte correta, não será fácil combinar (usando o endereço mac) o ip público correto com o link correto ip local. Aqui está o que eu poderia inferir de tabelas vizinhas de ambos os roteadores e do fato de que o fim do link local é o fim do mac:
box0 2001:db8:ee84:2180::1 <=> fe80::e69e:12ff:fe03:8b35
box2 2001:db8:2f13:1ea0::1 <=> fe80::0224:d4ff:febb:af9e
box3 2001:db8:399a:08f0::1 <=> fe80::e69e:12ff:fe02:10de
box4 2001:db8:399a:39e0::1 <=> fe80::0224:d4ff:fea7:f258
e o outro que não pôde ser encontrado pelos dados tem que ser:
box1 2001:db8:ee84:21c0::1 <=> fe80::e69e:12ff:fe04:286f
Com isso, fica claro que ambos os exemplos de ip -6 route get na pergunta mostram que a fonte errada foi usada para o roteador escolhido. Parece ser uma limitação do Linux nesse caso (ter várias LANs sobrepostas em uma única LAN física).
Então, aqui está o que deve ser feito para o roteador1. Além disso, por tentativa e erro "src" ainda tem que ser declarado para a rota padrão na tabela ou uma outra fonte ainda pode ser escolhida. Note que o IP público ou o IP local do link podem (devem) ser usados como gateway, então é melhor usar o IP público, mesmo que o RA pareça preferir o link ip, é mais fácil usar o público em um script e encontrar a correspondência entre os dois tipos de IP, como acima, não precisa mais ser feita.
# ip -6 route add 2001:db8:ee84:2180::/64 dev eth2 src 2001:db8:ee84:2180:200:24ff:fed1:3d9e table 100 # ip -6 route add default via 2001:db8:ee84:2180::1 dev eth2 src 2001:db8:ee84:2180:200:24ff:fed1:3d9e table 100 # ip -6 route add 2001:db8:ee84:21c0::/64 dev eth2 src 2001:db8:ee84:21c0:200:24ff:fed1:3d9e table 101 # ip -6 route add default via 2001:db8:ee84:21c0::1 dev eth2 src 2001:db8:ee84:21c0:200:24ff:fed1:3d9e table 101 # ip -6 route add 2001:db8:2f13:1ea0::/64 dev eth2 src 2001:db8:2f13:1ea0:200:24ff:fed1:3d9e table 102 # ip -6 route add default via 2001:db8:2f13:1ea0::1 dev eth2 src 2001:db8:2f13:1ea0:200:24ff:fed1:3d9e table 102 # ip -6 route add 2001:db8:399a:08f0::/64 dev eth2 src 2001:db8:399a:08f0:200:24ff:fed1:3d9e table 103 # ip -6 route add default via 2001:db8:399a:08f0::1 dev eth2 src 2001:db8:399a:08f0:200:24ff:fed1:3d9e table 103 # ip -6 route add 2001:db8:399a:39e0::/64 dev eth2 src 2001:db8:399a:39e0:200:24ff:fed1:3d9e table 104 # ip -6 route add default via 2001:db8:399a:39e0::1 dev eth2 src 2001:db8:399a:39e0:200:24ff:fed1:3d9e table 104
Pelo menos uma rota padrão "padrão" deve ser colocada na tabela principal (a usual), caso contrário, o que ocorrer depois, haverá um erro como "nenhuma rota para hospedar" ou "rede inacessível". Como você já tem 5 desses anúncios de roteador, não é necessário.
Agora vamos adicionar as regras que ligam cada IP de origem à sua tabela correspondente, selecionando a fonte correta para qualquer um dos roteadores (caixa):
# ip -6 rule add from 2001:db8:ee84:2180:200:24ff:fed1:3d9e table 100 # ip -6 rule add from 2001:db8:ee84:21c0:200:24ff:fed1:3d9e table 101 # ip -6 rule add from 2001:db8:2f13:1ea0:200:24ff:fed1:3d9e table 102 # ip -6 rule add from 2001:db8:399a:08f0:200:24ff:fed1:3d9e table 103 # ip -6 rule add from 2001:db8:399a:39e0:200:24ff:fed1:3d9e table 104
Também é possível forçar (ou até mesmo balancear com a coincidência statistic --mode nth ) uma escolha usando por exemplo ip6tables ... -j MARK ... com ip -6 rule add fwmark ... table 10x
Agora, seria melhor criar um script para isso ...
Pode haver outro problema. Se um roteador de caixa ficar off-line, a rota padrão correspondente desaparecerá rapidamente no sistema linux porque ele não é mais anunciado, mas o IP permanecerá. Não sei se esse IP ainda pode ser escolhido erroneamente para ser usado em uma rota padrão restante. Se isso acontecer, as regras de ip adicionadas podem substituir a rota padrão para usar o roteador de caixa agora off-line, derrotando assim o mecanismo de failover de ter várias caixas como roteadores. Eu não tenho meios para testar isso.