Estoy intentando utilizar TCP Anycast sin protocolos adicionales para conectar un cliente a uno de varios hosts con la misma IP de anycast.
Mi topología se ve de la siguiente manera:
El servidor en el medio es una máquina Ubuntu, que proporciona dos rutas para la dirección anycast.
Mi configuración de enrutamiento de múltiples rutas (en el enrutador) es:
`10.11.12.13 proto static
nexthop via 192.168.2.1 dev enp0s9 weight 1
nexthop via 192.168.3.1 dev enp0s10 weight 1`
La dirección anycast es 10.11.12.13y está asignada al loopback local de los dos enrutadores en el lado derecho. En el lado izquierdo hay un cliente con el enrutador en el medio como su puerta de enlace predeterminada.
Escenario 1: el enrutador en el medio inicia una sesión tcp con la dirección anycast como destino.
Escenario 2: el cliente en el lado izquierdo comienza una sesión tcp con la dirección de difusión ilimitada como destino.
Observación:
Al iniciar una sesión tcp desde el enrutador (ubuntu linux), todo funciona según lo deseado. El paquete SYN se reenvía a través de uno de cada saltos con la misma probabilidad. Cuando se establece una sesión, todos los paquetes de esta sesión pasan por el mismo salto, manteniendo viva la conexión (enrutamiento exitoso basado en flujo múltiple).
El problema ocurre en el escenario 2, cuando trato de establecer una sesión tcp del cliente en 192.168.1.1/24. El enrutador siempre reenvía los paquetes a solo uno de los hosts (el que tiene el sufijo IP 3.1). Si desconecto la conexión eth2 a este host, el enrutador reenvía los paquetes al segundo host. Pero al volver a poner eth2 nuevamente, la conexión vuelve al host en 3.1, lo que conduce a una desconexión entre el cliente y el host en el sufijo 2.1.
Solo puedo publicar un enlace de video, así que aquí hay un video que muestra cómo se ve desde la perspectiva del cliente: https://youtu.be/kthYK9uEwvM
Observe cómo el tcp SYN del cliente siempre se reenvía al host con el sufijo 3.1 ( esquina inferior derecha).
Terminales:
Enrutador: arriba a la izquierda, cliente: abajo a la izquierda, host 2.1: arriba a la derecha, host 3.1: abajo a la derecha.
Mi versión del kernel es el kernel 4.4 Linux. La sesión tcp se establece utilizando netcat (servidor) y telnet (cliente).
Cambiar el peso de los nexthops también solo afecta el enrutamiento desde el enrutador (192.168.1.254> 10.11.12.13).
¿Por qué el enrutador reenvía el paquete SYN de forma diferente cuando el paquete se envía desde el cliente que cuando se envía desde el enrutador?
¡Gracias por tu ayuda!
Respuestas:
Parece que este es un problema de ipv4.
El uso de ipv6 y una máquina ubuntu de Linux kernel 4.4 con casi la misma configuración funcionó como se esperaba. Enlace a la imagen de la topología
Aunque los mensajes ping de la ICPM siempre se enrutan a través del primer nexthop, los mensajes tcp se distribuyen equitativamente a lo largo de los nexthops. Las sesiones tcp establecidas parecen ser estables (por lo tanto, el núcleo identifica los flujos correctamente).
fuente