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;
host1 y host2 están conectados a través de router1 y router2 con 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.
- A menos que la conexión de su host final a su enrutador local sea el doble de la velocidad del tráfico que pasa por un solo enlace entre
router1y router2, 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;
bueno, IP SLA es la tecnología que se está utilizando al menos en un extremo hasta ahora ... :) aun así, lleva bastante tiempo para que ambos extremos detecten la falla del enlace, y la aplicación se desincroniza a veces ... y los enlaces pueden a veces parpadea ... por eso estamos buscando algo sin demoras
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 lleva bastante tiempo descubrir que la ruta que se considera operativa ahora está inactiva; finalmente, los enrutadores se dan cuenta de esto y cambian las rutas activas, pero lleva tiempo, y el protocolo de nivel de aplicación puede sufrir
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.