Resumen #
Este artículo explica cómo identificar y resolver problemas de enrutamiento asimétrico en un parche de RELIANOID implementación cuando el balanceador de carga tiene múltiples interfaces de red conectadas a diferentes subredes.
Esta situación puede ocurrir cuando los clientes frontend necesitan acceder a servicios backend ubicados en otra subred mientras el balanceador de carga tiene interfaces en ambas redes.
Un comportamiento de enrutamiento inadecuado puede provocar que el tráfico de respuesta salga por una interfaz diferente a la utilizada para la solicitud entrante, lo que da como resultado un enrutamiento asimétrico.
Descripción del problema #
En algunas implementaciones, el RELIANOID El equilibrador de carga está configurado con múltiples interfaces conectadas a diferentes redes.
La siguiente configuración es un entorno de ejemplo utilizado con fines demostrativos.
| Fácil de usar | Network | Propósito |
| eth0 | 192.168.1.0/24 | Gestión |
| eth1 | 192.168.110.0/24 | Frontend |
| eth2 | 192.168.100.0/24 | Aplicación / Backend |
Los servidores backend están ubicados en la subred 192.168.100.0/24 y se accede a ellos a través de granjas configuradas en el balanceador de carga.
Sin embargo, algunos clientes ubicados en la red 192.168.110.0/24 también necesitan acceder a servicios alojados en la red 192.168.100.0/24.
Debido a que el balanceador de carga tiene una interfaz en ambas redes y el reenvío de IP está activo por defecto, el sistema puede enrutar el tráfico de respuesta directamente a través de la interfaz frontal (eth1) en lugar de enrutarlo a través de la puerta de enlace esperada.
Esto da lugar a un enrutamiento asimétrico , que puede provocar fallos de conexión o pérdida de paquetes.
Ejemplo de configuración de interfaz #
¿Qué es el enrutamiento asimétrico? #
El enrutamiento asimétrico se produce cuando el tráfico entrante y saliente de la misma conexión sigue rutas de red diferentes.
Ejemplo de flujo #
Ruta de destino: 192.168.110.11 vía eth2 (Cliente) > 192.168.100.100 (Balanceador de carga) > 192.168.100.42 (Backend)
Ruta de retorno (incorrecta): 192.168.100.42 (Backend) > 192.168.100.100 (Balanceador de carga) > 192.168.110.11 vía eth1 (Cliente)
Debido a que el tráfico de retorno sale a través de una interfaz diferente, los dispositivos intermedios, como firewalls o enrutadores, pueden descartar los paquetes.
Cómo funcionan las tablas de enrutamiento #
RELIANOID usos tablas de enrutamiento por interfaz para controlar cómo se reenvía el tráfico entre redes.
Cada interfaz genera automáticamente su propia tabla de enrutamiento.
Tablas de enrutamiento de ejemplo: table_eth1, table_eth2
Estas tablas de enrutamiento definen:
- Rutas asociadas a la interfaz
- Puertas de enlace utilizadas para el reenvío de tráfico
- Interfaces a las que se les permite enrutar tráfico
Dentro de cada tabla de enrutamiento, las interfaces se pueden configurar como:
Interfaces administradas #
Interfaces a las que se les permite enrutar tráfico dentro de la tabla de enrutamiento haciendo uso de la función de reenvío de IP.
Interfaces no administradas #
Las interfaces que están excluidas de las decisiones de enrutamiento para esa tabla y el reenvío de IP no se aplicarán a esas interfaces.
Al controlar qué interfaces están administradas o no, los administradores pueden influir en cómo fluye el tráfico a través del balanceador de carga y evitar conflictos de enrutamiento.
Ejemplo de tabla de enrutamiento #
Solución #
Para resolver el problema de enrutamiento asimétrico, la interfaz en conflicto debe excluirse de la tabla de enrutamiento asociada con la red back-end.
En este escenario, eth1 debe eliminarse de la tabla de enrutamiento table_eth2, garantizando que el tráfico se enrute a través de la puerta de enlace correcta.
Solución usando la interfaz web #
- Vaya a: Red > Enrutamiento
- Seleccione la tabla de enrutamiento asociada con la interfaz de backend:
table_eth2 - Desplazarse hasta la parte inferior de la página.
- Localice la opción Interfaces administradas .
- Mover la interfaz eth1 desde Interfaces administradas a Interfaces no administradas.
Esto evita que el tráfico se enrute directamente a través de la interfaz frontend cuando se utiliza la tabla de enrutamiento del backend.
Solución usando CLI #
La misma configuración también se puede aplicar utilizando el RELIANOID CLI.
Paso 1: Habilitar el acceso a la API #
Vaya a: Sistema > Configuración de usuario
Habilite el acceso a la API y configure una clave API. Puede definir su propia clave o generar una aleatoria.
Después de crear la clave, cópiela y guárdela, ya que será necesaria la primera vez que acceda a la CLI usando noid-cli
Paso 2: acceso RELIANOID CLI #
Desde la consola del sistema, ejecute:
noid-cli
Introduzca la clave API cuando se le solicite.
Paso 3: Eliminar la interfaz de la tabla de enrutamiento #
Ejecute el siguiente comando:
tabla de enrutamiento de red no administrada agregar tabla_eth2 -interfaz eth1
Este comando evita que el tráfico se enrute a través de eth1 al utilizar la tabla de enrutamiento table_eth2.
Paso 4: Revertir la configuración (opcional) #
Si es necesario, la configuración se puede revertir con el siguiente comando:
tabla de enrutamiento de red no administrada eliminar tabla_eth2 eth1
BUENAS PRÁCTICAS #
- Realizar cambios de ruta durante horas de poco tráfico o ventanas de mantenimiento.
- Validar la conectividad después de aplicar la configuración.
- Asegúrese de que otros servicios no se vean afectados por los cambios de enrutamiento.
Conclusión #
Pueden ocurrir problemas de enrutamiento asimétrico cuando un balanceador de carga está conectado a múltiples redes y el tráfico regresa a través de una interfaz diferente a la utilizada para la conexión entrante.
In RELIANOIDEste problema se puede resolver ajustando las configuraciones de la tabla de enrutamiento y excluyendo las interfaces en conflicto de tablas de enrutamiento específicas.
Esto garantiza que el tráfico siga la ruta de red correcta y evita problemas de conectividad.
