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


7

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?


3
O TCP retransmite segmentos perdidos. Se você deseja zero perda de pacotes sem retransmissão, precisa de outra tecnologia além do TCP ... que problema de negócios você está resolvendo?
21813 Mike Pennington

11
sim, o TCP retransmite segmentos perdidos, mas com protocolos de roteamento como o BGP, leva bastante tempo para descobrir que a rota considerada operacional agora está inoperante; finalmente, os roteadores percebem isso e alternam rotas ativas, mas isso leva tempo e o protocolo no nível do aplicativo pode sofrer ... meu problema de negócios é o processamento de transações financeiras on-line.
Sergey Ushakov

11
o tempo limite padrão no nível do aplicativo é 40s; de fato, podemos permitir apenas uns 20 anos para a detecção de falhas na rota para evitar falhas na transação; sim, o aplicativo já está escrito, mas pode ser alterado; nenhuma criptografia no nível do aplicativo é usada; unicamente as ligações redundantes de longa distância são protegidos com IPsec
Sergey Ushakov

4
executar o seu próprio protocolo de roteamento IGP através dos túneis IPSec, opcionalmente com IP SLA e falhar como necessário ... este é um projeto bastante normal
Mike Pennington

11
o que você está usando para terminar os links ipsec? Cisco ASA ou um roteador, ou ??? Você não pode depender de detecção de um lado ... IP SLA em ambos os lados, ou um protocolo de roteamento irá corrigir seus problemas de detecção de falhas, se você ajustar os temporizadores hello adequadamente
Mike Pennington

Respostas:


0

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.


As recomendações de produtos ou recursos são explicitamente off-topic aqui, assim como os dispositivos de nível de consumidor, por exemplo, MikroTik.
Ron Maupin

@Netflow Obrigado por observar a ligação no modo de transmissão, independentemente do Mikrotik :) Não tenho certeza se vou tentar em um futuro próximo, mas ainda assim é bom saber que parece haver uma abordagem baseada em padrões. ..
Sergey Ushakov 27/02

10

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.


Mike, com todo o respeito, não posso aceitar suas críticas pelos seguintes motivos: 1) minha pergunta busca uma tolerância a falhas por tipo de solução de replicação , enquanto suas soluções são de tolerância a falhas por tipo de redundância ; ambas as abordagens são normalmente consideradas válidas, mas tendem a produzir níveis de qualidade de serviço diferentes, e busco um melhor nível de serviço; 2) a tolerância a falhas por replicação tende a ser mais cara, mas eu não levaria a palavra "caro" muito a sério aqui :) dizendo isso, aceite meu "obrigado" e vote de forma positiva para obter uma boa visão geral, mas evito aceitar sua resposta
Sergey Ushakov

11
@ sn-ushakov, como eu disse ... se você deseja tolerância a falhas por replicação, está usando o protocolo errado. O TCP foi criado para tolerância a falhas por redundância. Se você deseja tolerância a falhas por replicação, posso apresentá-lo ao nosso amigo conhecido como UDP . O UDP é muito mais adequado para o que você deseja; no entanto, que significa que você está prestes a reescrever a sua aplicação principal negócio só porque você está no amor com um projeto de rede estranho (sem hardware conhecidos para implementar essa replicação pacote bidirecional, devo acrescentar)
Mike Pennington

bem, às vezes o protocolo no nível do aplicativo não é a nossa escolha ... e o conhecimento da sua infraestrutura de colegas pode ser limitado no mundo dos negócios ... e pode ser legal ter, por exemplo, HTTP projetado e implementado no UDP :) e falando sério, obrigado por apontar para vincular protocolos de estado, eles podem ser um alívio, embora não sejam a solução final; BTW si TCP já tem disposição pelo menos para uma parte da solução que está sendo procurado: A TCP deve recuperar-se de dados que é ... duplicados ... - RFC 793, secção 1.5, subseção "Confiabilidade"
Sergey Ushakov

6
Sinta-se à vontade para citar a RFC 793, Seção 1.5 ... em resposta, citarei a RFC 1925, Seção (3) :With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.
Mike Pennington

2
A Engage Communications está vendendo uma solução TDM sobre IP. Você está pedindo uma solução TCP sobre IP ... você pode sobrepor IP sobre TDM sobre IP, mas novamente ... isso é realmente louco. Você deve contratar um engenheiro de rede real
Mike Pennington

4

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.


2
Ele não precisa deles, ele pode executar o MPLS sobre GRE, por exemplo, MPLS sobre IPSEC. Ele poderia investir em links L2, possivelmente? Quem sabe ou se importa com o orçamento dele, não eu; Não estou dizendo que minhas idéias são as melhores, estou simplesmente tentando fornecer soluções sãs e confiáveis, irrelevantes de custo ou disponibilidade, além de explicar melhor os problemas que ele enfrenta e os motivos para fazer uma escolha em detrimento de outra. É uma resposta puramente técnica.
jwbensley

11
@ sn-ushakov Não existe tempo zero
jwbensley 29/07

11
Não diz nesse documento, para repetir a minha auto Time must pass for possible events to become actualities- não existe tempo zero. A caixa deve verificar se há perdas, atrasos, quedas, etc., isso leva tempo, pode demorar mili ou microssegundos, mas leva algum tempo. Assim como o BFD, por exemplo, se você definir o tempo de olá para 50ms, com um tempo de espera padrão de 3x olá, precisará aguardar 150ms para que ocorra o failover. Agora, pare de comparar uma solução de backup TDM com o seu cenário. Por sua própria natureza, é possível escritório um serviço de TDM como a redundância TCP você precisar
jwbensley

11
... porque você sabe quando um pacote TDM deve chegar exatamente. Se você não entender completamente como os E1s / T1s funcionam, sugiro que você leia sobre isso primeiro. Você entenderá que um dos motivos para ter links TDM é a confiabilidade, como latência garantida. Eles rodam a uma velocidade fixa e taxa de quadros por segundo. IP / TCP está em toda a escala. O TDM é muito mais previsível e isso é executado em uma camada inferior à do TCP, seria como duplicar quadros Ethernet em dois links. O fato de que estas caixas estão executando TDM sobre IP adiciona em algum potencial para a mudança e desviando dos dois fluxos TDM, por isso ...
jwbensley

11
... essas caixas têm temporizadores inclinados e detectores de quadros fora de ordem (leitura de números de sequência).
jwbensley

1

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.


desculpe, mas não posso concordar que este é um problema da camada de aplicativo; o aplicativo tem o direito de esperar apenas um link TCP de qualidade suficiente; O próprio TCP possui provisões para recuperação após pequenas falhas de rede e existem inúmeras soluções que fornecem tolerância a falhas de rede por roteamento alternativo; infelizmente, todos eles que eu conheço são do tipo recuperar-rápido-após-falha, em vez de não precisar recuperar ; Eu percebo essa tarefa apenas como redundante de engenharia de rede; afinal, se podemos ter um RAID, por que não podemos ter um RAIN? :)
Sergey Ushakov

Duas NICs com duas sessões tcp significam que o OP deve decidir qual sessão TCP é mais confiável.
radio-free-europe

Apenas para evitar mal-entendidos: eu nunca quis dizer duas sessões de TCP. A sessão TCP deve ser uma. Essa é a tarefa dos roteadores de cuidar da redundância e do failover de tráfego TCP com atraso zero.
Sergey Ushakov 29/07

0

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!


parece promissor e adequado (embora não seja de nível industrial), mas infelizmente o GitHub já responde com 404 para este projeto ... você sabe o que aconteceu com esse projeto depois?
Sergey Ushakov

infelizmente eu não. Pode ser necessário entrar em contato diretamente com os autores.
smoothbSE
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.