Estoy buscando una tecnología para lograr la tolerancia a fallas de conexión TCP con la ayuda de dos enlaces entre hosts y sin demoras para la detección de fallas de ruta. Algo como esto:
link1 packet1copy1->
--------------------------
packet1-> / \ packet1copy1/packet1copy2->
host1--------router1 router2 ------------------------host2
\ link2 packet1copy2-> /
--------------------------
host1y host2están conectados a través de router1y router2con dos enlaces entre ellos. Cada enrutador duplica cada paquete que proviene de los hosts antes de reenviarlos a ambos enlaces simultáneamente. Luego, el enrutador par o la pila IP del host de destino se encargan de la eliminación redundante de paquetes.
Editar: De hecho, esta es una búsqueda de una solución de tolerancia a fallas por replicación de uso general para el transporte TCP (IP). La solución debe ser del tipo sin necesidad de recuperación en lugar de enfoques razonablemente rápidos de recuperación como BGP / OSPF / Cisco IP SLA, etc. Algunas soluciones de redundancia de paquetes patentadas ya son conocidas, aunque no lo suficientemente universales. En particular, Engage Communication ofrece IP Tube Protector para VoIP. Desafortunadamente, esta solución 1) es más un equipo que una tecnología estándar y 2) se limita solo al dominio VoIP. También puede valer la pena señalar la tecnología de redundancia de paquetes de Juniper , aunque parece limitarse a un solo enlace y no a enlaces redundantes.
Me pregunto por qué no puedo encontrar algo similar de Cisco ... ¿Alguna tecnología estándar o al menos de propósito general aborda esto?
fuente
Respuestas:
Con los enrutadores Mikrotik, puede usar la vinculación en modo de transmisión, ver vinculación . Hice algunas pruebas a través de una conexión de enlace 4G, reduce la pérdida de paquetes de 1 a 2 y me beneficio de las mejoras de velocidad de TCP. Las pérdidas de paquetes no se eliminan por completo, pero ir a 3 enlaces no mejora más. Investigaría a continuación en TCP codificado en red.
fuente
Hay algunas cosas que funcionan en contra de su propuesta ...
Voy a responder con el mismo comentario que hice, ya que sus requisitos de detección de fallas son veinte segundos ...
Construya 2 túneles IPSec con diversidad de ISP según sea necesario. Ejecute un protocolo de enrutamiento a través de sus túneles IPSec y ajuste los temporizadores de protocolo para fallar alrededor de la pérdida sostenida de paquetes de infraestructura. Si tiene Cisco de extremo a extremo, EIGRP ha tenido una convergencia muy rápida en torno a las fallas, aunque los protocolos de estado de enlace se están volviendo lo mismo en estos días con las implementaciones alternativas sin bucle IETF.
Opcionalmente, use IP SLA en ambos lados para derribar un túnel que no cumpla con los requisitos de jitter / delay / packet loss.
fuente
With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.OK, desde arriba;
Abajo vota tu pregunta de mí; su pregunta no es lo suficientemente clara según sus respuestas en los comentarios a las respuestas de otras personas. Has asumido que la solución está relacionada con la ingeniería de redes, pero no pareces saberlo, y das la impresión de que esperas que alguien te dé la respuesta que necesitas.
Tiene el siguiente requisito de problema;
router1yrouter2, que no ha mencionado, sus hosts necesitarán dos conexiones a su enrutador local. Hay NO software nativo o producto en cualquier lugar que puede funcionar con una gama anfitriones y tomar dos flujos TCP por el mismo NIC o dos separadas y el tirón de una corriente alterna paquetes de la primera corriente de falta. ¿Cómo se esto? Debido a que no es así como funcionan las redes, IP y TCP simplemente no fueron diseñadas para funcionar así. Puede haber productos para duplicar paquetes, pero estos son un nicho, no muy extendido, porque es la respuesta incorrecta a la pregunta.¿Por qué es esta una solicitud tan loca?
Parece que estás tratando de poner una clavija redonda en un agujero cuadrado. Entiendo que el requisito de su problema es que desea redundancia para los datos de su aplicación que viajan entre hosts remotos. Los datos se envían dos veces de extremo a extremo en caso de falla del enlace. Sin embargo, eso es todo lo que está protegiendo aquí con flujos TCP duales, falla de la capa física 1. Si hay una pausa en el envío de un paquete de un host a otro, llegará tarde a ambos enlaces de enrutador a enrutador. Si se produce un problema transitorio en un enlace pero no en el otro, como la congestión, el enrutador al final del enlace necesitaría rastrear ambas secuencias TCP simultáneamente para ver que cuando un paquete llega al enlace 2 con el número de secuencia en curso en su encabezado, y no ha llegado nada en link1, entonces el paquete en link1 llega tarde, y si aparece, necesita descartarlo.
¿Qué pasa si te encuentras en una situación en la que hay congestión en link1 pero no se cae el tráfico, debido a un buen esquema de QoS, pero son colas, los paquetes de link1 están siempre detrás de link2? ¿Qué pasa si link2 falla ahora y el enrutador pasa los paquetes en link1 a los hosts finales? Va a recibir paquetes duplicados y se detendrá y retransmitirá, etc. y causará un retraso. Aquí no se logró nada.
Pasando a una solución;
Una mejor idea en mi opinión sería tener enlaces de doble capa 2 entre los dos hosts finales, extendiendo sus dominios de difusión para incluir NIC entre sí. Puede hacerlo a través de interconexiones directas de capa 2, extensión MPLS / VPLS, servicio de capa 2 de operador, elija, eso no es estrictamente relevante aquí. La extensión de la red de capa 2 entre los hosts significa que no necesita meterse con TCP o hacer ningún tipo de corrección de magia negra o curita. TCP será completamente independiente de la tecnología subyacente y aún tendrá su redundancia de capa 1 / enlace físico.
Si usa una solución basada en MPLS, puede usar funciones como la ingeniería de tráfico (MPLS-TE) para monitorear la latencia en los enlaces y siempre usar el enlace con la latencia más baja. Puede usar BFD con MPLS FRR, que puede obtener 50 ms ~ fallas con el tiempo entre enlaces. Sé que dijiste que no quieres una solución de falla por redundancia, pero 50ms es bastante rápido en mi opinión. Si su aplicación no puede manejar una pérdida de conectividad de 50 ms, debe volver al tablero de dibujo de la aplicación. Ningún sistema está activo el 100% del tiempo, debe planificar las fallas, el mantenimiento planificado y las interrupciones debido a intenciones maliciosas / relacionadas con la seguridad; a todos ocurren en algún momento. Debes ser realista.
En un comentario dijiste lo siguiente;
No hay tal cosa; Debe pasar el tiempo para que los posibles eventos se conviertan en realidades. Debe repensar esto con un nivel de demora "aceptable".
También en otro comentario que dijiste;
BGP tiene un temporizador de saludo, esto detecta la presencia de su vecino inmediato. El valor predeterminado es 30 segundos, sospecho que esto es a lo que se refiere también. Si ambos enrutadores en su topología hablan BGP con el ISP en cada sitio o incluso directamente entre sí, sobre esos pares construya túneles IP en IP de túneles GRE o L2TP (v3) entre los dos enrutadores, sobre esos túneles ejecute BFD o IP SLA. Ahora puede detectar la pérdida de conectividad de extremo a extremo en 1 o 2 segundos y redirigir al otro túnel utilizando objetos de tachuelas.
Con todo, parece que estás mezclando diferentes capas de tecnología. Se supone que BGP no proporciona un enrutamiento rápido, no se supone que TCP esté duplicado, etc. Estás viendo los niveles incorrectos de abstracción para abordar este problema. Espero que esto haya ayudado.
fuente
Time must pass for possible events to become actualities: no existe el tiempo cero. La caja tiene que verificar pérdidas, retrasos, caídas, etc., eso lleva tiempo, puede ser mili o micro segundos, pero lleva algún tiempo. Al igual que BFD, por ejemplo, si establece el tiempo de saludo en 50 ms, con un tiempo de espera predeterminado de 3 veces, debe esperar 150 ms para que se produzca la conmutación por error. Ahora, deje de comparar una solución de respaldo TDM con su escenario. Por su propia naturaleza, es posible ofrecer un servicio TDM como la redundancia TCP que necesitaEste es un problema de la capa de aplicación y no un problema de nivel de red. Esto se debe a que uno de los principios básicos de IP es evitar duplicados, especialmente cuando se invoca la retransmisión TCP.
En entornos muy críticos, el enfoque será tener 2 NIC en los hosts finales y lograr que la aplicación genere 2 paquetes únicos. Con este enfoque, puede utilizar las tecnologías existentes y los principios de red utilizando rutas y métricas variables.
fuente
No conozco trucos o protocolos que puedan realizar este tipo de replicación directa en los dispositivos de red en cuestión; para este tipo de aplicación, recomendaría la redundancia y la detección rápida de fallas utilizando BGP fast-failover, BFD y otras herramientas. Sin embargo, me encontré con este proyecto de código abierto llamado 'Tunnel Splitter' http://coderrr.wordpress.com/2010/01/10/tunnel-splitter-accelerating-a-single-tcp-connection-over-multiple-isps/eso parece ajustarse a lo que estás buscando. En resumen, los cuadros TS instalados en cada sitio proxy las conexiones TCP entre host1 y host2, y luego dividieron el tráfico entre ellos a través de túneles. Como cada túnel tiene una dirección de origen única, se puede usar PBR (enrutamiento basado en políticas) en los enrutadores para dirigir el tráfico para tunnel1 sobre link1 y tunnel2 sobre link2. Los cuadros TS terminan los túneles y tienen una única conexión tcp a host1 y host2. Por supuesto, necesitaría probar esto realmente, ¡pero parece funcionar en la pizarra!
fuente