¿Cómo lograr el enrutamiento de múltiples rutas por paquete en Linux?

Linux Kernel antes de 3.6 usaba el almacenamiento en caché de rutas para realizar el enrutamiento de múltiples rutas IPv4, lo que significaba que el enrutamiento entre dos líneas / ISP separadas era bastante fácil. A partir de 3.6, el algoritmo cambió a ser por paquete, lo que significa que se necesitaron algunos trucos de marcador de tabla de ruta / regla / tablas ip para lograr las dos líneas / ISP.

Sin embargo, si tuviera dos líneas con el mismo ISP que pudiera enrutar una sola IP por ambas líneas por paquete de forma equilibrada / conmutación por error, entonces desde 3.6 podría lograr fácilmente la vinculación de línea (a nivel de IP) debido a el enrutamiento por paquete en ambas direcciones.

A partir de 4.4, el kernel cambió nuevamente al equilibrio de carga basado en el flujo basado en un hash sobre las direcciones de origen y destino.

Actualmente estoy ejecutando Kernel 4.4.36, y estoy usando enrutamiento de múltiples rutas sobre conexiones PPPoE. Mi tráfico descendente desde el ISP se enruta a través de las dos líneas separadas por paquete (una IP enrutada por ambas líneas). Esto me da una velocidad de descarga más rápida que la velocidad de una línea individual. Casi la velocidad de ambas líneas sumadas. Funciona muy bien, video de Skype, VoIP (UDP), YouTube, etc. todo funciona muy bien

Debido a que tengo una experiencia tan buena en sentido descendente, quiero probarlo en sentido ascendente, pero mi tráfico ascendente se enruta de acuerdo con el algoritmo basado en flujo más nuevo en ambos dispositivos ppp (que tienen la misma dirección IP). Esto significa que no puedo lograr una velocidad de carga que sea más rápida que la velocidad de una sola línea.

¿Hay alguna forma de configurar el Kernel actual para usar el algoritmo por paquete? ¿O algún otro método para lograr el enrutamiento de múltiples rutas por paquete? ¿Tendría que volver a un kernel anterior (que no quiero hacer por otras razones)?

Mi ISP no admite ppp multienlace.

En caso de que sea relevante, actualmente estoy ejecutando Arch Linux ARMv7 en una Raspberry Pi 3.

— bao7uo
fuente

Esta es una muy mala idea. El balance por paquete en L2 (es decir, MLPPP) incluye suficiente lógica para volver a ensamblar los paquetes en orden. Ejecutar esto sobre IP deja abierta una tremenda oportunidad (si no una certeza cercana) para la entrega fuera de orden. Esto causará una gran cantidad de problemas con sesiones TCP lentas, UDP completamente roto, problemas con cualquier tipo de transmisión en tiempo real, etc. El otro problema es que incluso si está enviando paquetes por turnos a su ISP, hay absolutamente ninguna sugerencia de que se equilibrarán de manera similar hacia usted.

— rnxrx

@rnxrx gracias por tu comentario: he editado la pregunta para proporcionar detalles adicionales. De mi pregunta: "el tráfico aguas abajo del ISP se enruta a través de las dos líneas separadas por paquete". El ISP proporciona un panel de control: cuando elijo una IP que se enrutará a través de ambas líneas, entonces la enrutan en una operación por turnos perfectamente equilibrada por paquete. Funciona bien, a aproximadamente el 90% del total de las velocidades de ambas líneas sumadas, y proporciona conmutación por error instantánea. De vídeo de Skype, llamadas de VoIP, YouTube, la BBC de streaming, etc. Todos los grandes - una experiencia fantástica aguas abajo hace que quiera tratar aguas arriba

— bao7uo

Ahh, lo tengo ... Entonces, ¿tiene actualmente dos IP únicas (una por conexión) o están enrutando a una sola IP (o una subred) en su lado a través de dos rutas paralelas? Si está ejecutando cualquier tipo de NAT, obviamente es crucial que ocurra antes de este equilibrio. De todos modos, ¿has echado un vistazo a support.aa.net.uk/… ? Está utilizando extensiones de iptables para lograr básicamente lo que está describiendo y, como tal, debería ser bastante consistente en las versiones de kernel razonablemente modernas.

— rnxrx

Gracias @rnxrx: sí, puedo hacer cualquier opción (dos IP únicas o una sola IP a través de las rutas paralelas). He preferido la opción de IP única, ya que parecía tener más sentido.

— bao7uo

Ok, entonces después de haber tenido más tiempo para investigar esto, encontré una manera de hacerlo usando Linux TEQL (True Link Equalizer). Aquí hay un enlace que seguí libremente, pero con algunos ajustes.

http://lartc.org/howto/lartc.loadshare.html

Así es como lo conseguí trabajando en Arch Linux ARMv7 (Raspberry Pi 3)

En el arranque:

El siguiente comando debe ejecutarse en el arranque para cargar el módulo Kernel apropiado.

modprobe sch_teql

Los siguientes comandos también se ejecutan en el arranque, suponiendo que desea NAT desde una red local en eth0.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

El tráfico de retorno FORWARD está en ppp +, y la MASCARÍA POSTROUTING en teql + porque el tráfico saliente sale en teql y el tráfico de retorno regresa en ppp.

Cuando aparecen los enlaces ppp:

Suponiendo que los enlaces para equilibrar la carga son ppp, los siguientes comandos se ejecutarán en un script en un /etc/ppp/ip-up.d/script.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

¿Dónde 1.1.1.1está su dirección IP pública de cara al ISP? Se pueden asignar IP públicas adicionales al dispositivo teql0, pero no es necesario asignarlas a los dispositivos ppp. En mi configuración, los dos enlaces ppp comparten la misma IP (negociada por pppoe, etc.) El enlace teql se asignó manualmente como se muestra arriba. El ISP debe enviar el tráfico para la IP por igual en ambos enlaces.

La ruta inversa ( rp_filter) se establece en 2(suelta) tanto en el script anterior para que los paquetes de retorno no se descarten debido a que vuelven a las interfaces ppp en lugar de teql0.

Lo configuré de esa manera y funciona perfectamente. ¡Muy fácil! Cuando los enlaces fallan, hay una conmutación por error perfecta. Cuando aparecen, comienzan a trabajar nuevamente. Parece que no hay pérdida de paquetes o retraso cuando falla, y tampoco cuando vuelve a funcionar.

Además, uno de los comentaristas sugirió el siguiente enlace que utiliza el enrutamiento de políticas, con iptables para marcar todos los demás paquetes, etc. pero intentaré en unos días ver si funciona mejor que el anterior y proporcionaré comentarios aquí en consecuencia.

http://support.aa.net.uk/Router_-_Linux_upload_bonding_using_policy_routing

— bao7uo
fuente

Nunca probé el enrutamiento de políticas porque el TEQL funcionó muy bien. Si no está roto ...

— bao7uo

Estoy tratando de hacer que esto funcione. Tengo el enlace funcionando, puedo usar la interfaz unida del enrutador. Sin embargo, no puedo hacer que el NAT funcione, el tráfico de mi LAN no desciende por el enlace enlazado :(

— andynormancx

si publica una nueva pregunta sobre la falla del servidor y la vincula desde un comentario, intentaré resolverla por usted. ¿incluye tanta información como sea posible, como configuración de interfaz / ip, tabla de enrutamiento, reglas de iptables, etc. a menos que pueda incluir toda la información aquí en los comentarios?

— bao7uo

PD. Acabo de notar un error en mi configuración. dijo, sysctl -w net.ipv4.ip_forwardpero debería decirlo, sysctl -w net.ipv4.ip_forward=1lo he corregido anteriormente. Eso ciertamente evitaría que el tráfico de la LAN descienda por el enlace enlazado.

— bao7uo

No creo que eso fue lo que dejó de funcionar para mí, tenía el reenvío habilitado en sysctl. Ahora estoy tratando de averiguar si se espera la gran cantidad de paquetes fuera de servicio que estoy viendo.

— andynormancx