Vamos supor que eu configurei um par de servidores DNS anycasted na minha rede interna usando o bird e eles estão apenas falando OSPF com meus roteadores principais. Eu encontrei este em a internet e fez acontecer.
Se eu configurar um para ter um caminho de custo mais alto do que o outro, doce, acabei de fazer uma maneira divertida de fazer failover sem causar a meus clientes qualquer tempo limite ao alternar de um host em seu resolv.conf para o outro resolvedor em seu resolv.conf.
Mas isso não é bom o suficiente para mim. Eu quero distribuir minha carga entre meus servidores DNS. Então eu configurei o custo para ambos serem os mesmos, então os roteadores agora deveriam estar fazendo o ECMP e enviando 50% dos pedidos para um e 50% dos pedidos para o outro.
Mas acontece que minha empresa usa o TCP em uma grande parte do nosso DNS - digamos que temos registros SRV enormes e usamos o DNSSEC porque somos incríveis.
Agora, como configuro minha configuração anycast inteligente para lidar com o fato de que as solicitações TCP precisam de 3 ou 4 pacotes para que uma solicitação seja feita e agora um desses 3 pacotes sempre irá para o roteador errado e o reset da conexão tcp.
Bem, em tal esquema você pode simplesmente bloquear as respostas do RST para uma sessão inválida, não é? :) ou (o que é ainda melhor), não o coloque em serviço:
- estado inválido?
- não, tente outro !
S. Sim, eu gosto muito da apresentação " TCP Anycast - Não acredite no FUD - nanog "pelo link que eu te dei nos comentários. ;)
Use apenas o ECP OSPF por fluxo em vez de por pacote e você ficará bem, como a apresentação do NANOG diz.
Anycast para TCP é apenas um problema em potencial para sessões TCP de vida longa, e quase todas as implementações de DNS que eu conheço usam apenas sessões TCP de curta duração.