OK, de cima;
Vote na sua pergunta de mim; sua pergunta não é clara o suficiente com base nas suas respostas nos comentários às respostas de outras pessoas. Você assumiu que a solução está relacionada à engenharia de rede, mas parece que não sabe e dá a impressão de que espera que alguém lhe dê a resposta que você precisa.
Você tem o seguinte requisito de problema;
host1 e host2 são conectados via roteador1 e roteador2 com dois links entre eles. Cada roteador duplica todos os pacotes provenientes de hosts antes de encaminhá-los para os dois links simultaneamente. Em seguida, o roteador de mesmo nível ou a pilha de IPs do host de destino cuidam da eliminação de pacotes redundantes.
- A menos que a conexão do host final com o roteador local seja o dobro da velocidade do tráfego passando por um único link entre
router1
e router2
, o que você não mencionou, seus hosts precisarão de duas conexões com o roteador local. Há NO software nativo ou produto em qualquer lugar que pode ser executado em um fim anfitriões e levar dois TCP flui para baixo o mesmo NIC ou duas separadas e puxar a partir de um fluxo alternativo pacotes a partir do primeiro fluxo de falta. Como eu sei disso? Como não é assim que a rede funciona, o IP e o TCP simplesmente não foram projetados para funcionar assim. Talvez existam produtos para duplicar pacotes, mas esse é um nicho, e não um spread amplo, porque é a resposta errada para a pergunta.
Por que esse é um pedido maluco?
Você parece estar tentando colocar um pino redondo em um buraco quadrado. Minha compreensão do seu requisito de problema é que você deseja redundância para os dados do seu aplicativo que viajam entre hosts remotos. Os dados são enviados duas vezes de ponta a ponta em caso de falha no link. Isso é tudo contra o qual você está protegendo aqui com fluxos TCP duplos, falha da camada física 1. Se houver uma pausa no envio de um pacote de um host para outro, será tarde a chegada dos links de roteador a roteador. Se um problema transitório ocorrer em um link, mas não no outro, como congestionamento, o roteador no final do link precisaria rastrear os dois fluxos TCP simultaneamente para verificar se, quando um pacote chega ao link2, com o número de sequência em seu cabeçalho e nada chegou ao link1, o pacote no link1 está atrasado e, se aparecer, será necessário removê-lo.
E se você se encontrar em uma situação em que há congestionamento no link1, mas nenhum tráfego é eliminado, devido a um bom esquema de QoS, mas são filas, os pacotes fora do link1 agora estão sempre atrás do link2. E se o link2 falhar agora e o roteador passar pacotes no link1 para os hosts finais, ele receberá pacotes dup, parará e retransmitirá etc, causando um atraso. Nada foi alcançado aqui.
Passando para uma solução;
Uma idéia melhor, na minha opinião, seria ter links de dupla camada 2 entre os dois hosts finais, estendendo seus domínios de transmissão para incluir os outros NICs. Você pode fazer isso por meio de interconexões diretas da camada 2, extensão MPLS / VPLS, serviço de camada 2 da operadora, escolha, que não é estritamente relevante aqui. Estender a rede da camada 2 entre hosts significa que você não precisa mexer com o TCP ou executar qualquer tipo de magia negra ou correções do tipo band-aid. O TCP será totalmente independente da tecnologia subjacente e você ainda terá a camada 1 / redundância de link físico.
Se você usar uma solução baseada em MPLS, poderá usar recursos como engenharia de tráfego (MPLS-TE) para monitorar a latência nos links e sempre usar o link com a menor latência. Você pode usar o BFD com MPLS FRR, que pode obter 50ms ~ de falha ao longo do tempo entre os links. Sei que você disse que não deseja uma solução de failover de redundância, mas 50ms é bastante rápido na minha opinião. Se o seu aplicativo não conseguir lidar com uma perda de conectividade de 50ms, será necessário voltar à área de desenho do aplicativo. Nenhum sistema funciona 100% do tempo; você deve planejar falhas, manutenção planejada e interrupções por meio de intenções / segurança maliciosas; tudo ocorre em algum momento. Você deve ser realista.
Em um comentário, você disse o seguinte;
bem, IP SLA é a tecnologia que está sendo usada pelo menos em uma extremidade até agora ... :) ainda leva bastante tempo para ambas as extremidades detectarem falha no link, e o aplicativo às vezes fica fora de sincronia ... e os links podem estar brilhando às vezes ... é por isso que estamos procurando algo sem atrasos
Não tem isso; O tempo deve passar para que possíveis eventos se tornem realidades. Você precisa repensar isso com um nível de atraso "aceitável".
Também em outro comentário você disse;
BGP leva bastante tempo para descobrir que a rota considerada operacional está agora em baixo; finalmente, os roteadores percebem isso e alternam rotas ativas, mas isso leva tempo e o protocolo no nível do aplicativo pode sofrer
O BGP tem um temporizador de olá, isso está detectando a presença de seu vizinho imediato. O padrão é 30 segundos, eu suspeito que isso é o que você está se referindo também. Se os dois roteadores em sua topologia falam BGP com o ISP em cada site ou mesmo diretamente entre si, através desses pares construa túneis IP-in-IP de túneis GRE ou L2TP (v3) entre os dois roteadores, nesses túneis execute BFD ou SLA IP. Agora você pode detectar a perda de conectividade de ponta a ponta em 1 ou 2 segundos e redirecionar para o outro túnel usando objetos de aderência.
Em suma, você parece estar misturando diferentes camadas de tecnologia. O BGP não deve fornecer roteamento rápido, o TCP não deve ser duplicado e assim por diante. Você está olhando para os níveis errados de abstração para resolver esse problema. Espero que isso tenha ajudado.