Agregação de link IP redundante para operação de failover sem detecção de falha de rota

Estou procurando uma tecnologia para obter tolerância a falhas de conexão TCP com a ajuda de dois links entre hosts e sem atrasos na detecção de falhas na rota. Algo assim:

                       link1   packet1copy1->
                     --------------------------
      packet1->     /                          \    packet1copy1/packet1copy2->
host1--------router1                            router2 ------------------------host2
                    \  link2   packet1copy2->  /
                     --------------------------

host1e host2são conectados via router1e router2com 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 IP do host de destino cuidam da eliminação de pacotes redundantes.

Edit: Esta é, de fato, uma pesquisa para uma solução de tolerância a falhas por replicação de uso geral para transporte TCP (IP). A solução deve ser do tipo não é necessário recuperar, em vez de abordagens razoavelmente rápidas para recuperar , como BGP / OSPF / Cisco IP SLA, etc. Algumas soluções proprietárias de redundância de pacotes já são conhecidas, embora insuficientemente universais. Em particular, a Engage Communication oferece o IP Tube Protector para VoIP. Infelizmente, esta solução 1) é mais um equipamento do que uma tecnologia padrão e 2) está confinada apenas ao domínio VoIP. Também vale a pena notar a tecnologia Juniper Packet Redundancy , embora pareça limitada apenas ao link único e não a links redundantes.

Eu me pergunto por que não consigo encontrar algo semelhante da Cisco ... Alguma tecnologia padrão ou pelo menos de uso geral aborda isso?

Com os roteadores Mikrotik, você pode usar a ligação no modo de transmissão, consulte a ligação . Fiz alguns testes em uma conexão de link 4G, reduz a perda de pacotes de 1 para 2 e me beneficio das melhorias na velocidade do TCP. As perdas de pacotes não são completamente eliminadas, mas a passagem para 3 links não melhora ainda mais. Eu investigaria em seguida na rede codificada TCP.

Estou procurando uma tecnologia para obter tolerância a falhas de conexão TCP com a ajuda de dois links entre hosts e sem atrasos na detecção de falhas na rota. Algo assim:

                       link1   packet1copy1->
                     --------------------------
      packet1->     /                          \    packet1copy1/packet1copy2->
host1--------router1                            router2 ------------------------host2
                    \  link2   packet1copy2->  /
                     --------------------------

Há algumas coisas trabalhando contra a sua proposta ...

1. Você fará o host1 e o host2 trabalharem muito para desembaraçar seu esquema de duplicação intencional de pacotes sem uma boa razão
2. Você está consumindo cavalos de força nos seus pontos de criptografia ipsec sem uma boa razão
3. O TCP foi aprimorado por mais de três décadas para se recuperar automaticamente de falhas e falhas na infraestrutura; "ajudar" o TCP de maneira a corrigir o problema errado. Você precisa fazer com que sua infraestrutura reaja para atenuar os problemas; não deve usar fita adesiva TCP para sobreviver à infraestrutura problemática.

Vou responder com o mesmo comentário que fiz, já que seus requisitos de detecção de falhas são de vinte segundos ...

Crie 2 túneis IPSec com diversidade de ISP, conforme necessário. Execute um protocolo de roteamento pelos túneis IPSec e ajuste os cronômetros de protocolo para falhar na perda de pacotes de infraestrutura sustentada. Se você possui Cisco de ponta a ponta, o EIGRP tem tido uma convergência muito rápida em torno de falhas, embora os protocolos de estado do Link estejam obtendo o mesmo hoje em dia com as implementações alternativas livres de loop IETF.

Opcionalmente, use o IP SLA de ambos os lados para derrubar um túnel que não atende a nenhum requisito de tremulação / atraso / perda de pacotes.

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 router1e 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.

Esse é um problema da camada de aplicativo e não do nível da rede. Isso ocorre porque um dos princípios básicos do IP é evitar duplicatas, especialmente quando a retransmissão TCP é invocada.
Em ambientes altamente críticos, a abordagem será ter 2 NICs nos hosts finais e fazer com que o aplicativo gere 2 pacotes exclusivos. Com essa abordagem, você pode usar tecnologias e princípios de rede existentes usando caminhos e métricas variáveis.

Não conheço truques ou protocolos que possam executar esse tipo de replicação direta nos dispositivos de rede em questão - para esse tipo de aplicativo, recomendo redundância e detecção rápida de falhas usando o BGP fast-failover, BFD e outras ferramentas. No entanto, me deparei com este projeto de código aberto chamado 'Tunnel Splitter' http://coderrr.wordpress.com/2010/01/10/tunnel-splitter-accelerating-a-single-tcp-connection-over-multiple-isps/isso parece se encaixar no que você está procurando. Em resumo, as caixas TS instalaram em cada site proxy as conexões TCP entre o host1 e o host2 e, em seguida, dividiram o tráfego entre eles pelos túneis. Como cada túnel possui um endereço de origem exclusivo, o PBR (roteamento baseado em políticas) pode ser usado nos roteadores para direcionar o tráfego para o túnel1 pelo link1 e o túnel2 pelo link2. As caixas TS terminam os túneis e têm uma única conexão TCP ao host1 e host2. Claro, você precisaria realmente testar isso, mas parece funcionar no quadro branco!