Sucede que me cruzo con clientes que tienen lo que yo defino como un «enrutamiento asimétrico» en sus redes. En pocas palabras, tienen dos puertas de enlace en la misma subred IP. Los clientes están configurados para apuntar a una puerta de enlace (es decir, 172.16.1.1) pero hay otro dispositivo (es decir, 172.16.1.2) que se conecta y enruta a algún lugar. En general, he visto este tipo de configuración cuando hay 2 tipos diferentes de conexiones WAN: 1 conexión a Internet y 1 conexión MPLS corporativa.
Personalmente, no me atrae el tipo de diseño de red anterior: cada La subred debe tener una sola puerta de enlace. Desde mi punto de vista, el escenario anterior puede crear algunos problemas para los clientes, porque envían un paquete a su puerta de enlace predeterminada (172.16.1.1) y esos paquetes luego se reenvían al otro enrutador (172.16.1.2) y cuando son respondidos a, llegan al cliente simplemente pasando por 172.16.1.2. Los clientes esperarían o deberían esperar que los paquetes de respuesta provengan de 172.16.1.1, ¿o me equivoco aquí?
Me complacería tener sus opiniones y puntos de vista técnicos sobre este problema.
Comentarios
- ¿Alguna respuesta te ayudó? Si es así, debes aceptar la respuesta para que la pregunta no ‘ t se mantenga apareciendo para siempre, buscando una respuesta. Alternativamente, puede publicar y aceptar su propia respuesta.
Responder
Le recomendaría que consulte los protocolos de redundancia de primer salto como HSRP o VRRP.
En realidad, tener dos puertas de enlace puede ser un muy buen diseño de red, porque si un enrutador fallara, el otro enrutador puede tomar sin problemas. Sin embargo, como ya sabe, no es fácil hacer esta transición si tiene que realizar una reconfiguración manual de cada cliente en una subred.
Protocolos como HSRP (o VRRP si tiene equipo que no es de Cisco) le permiten tener dos (o más) enrutadores (o conmutadores L3 s) en una subred comparten una única dirección IP. Tendrá su primer enrutador con una dirección de .2, el segundo con una dirección de .3 y una «dirección IP virtual» de .1 que ambos enrutadores conocen a través de la configuración. Cuando el enrutador principal falla, el secundario es capaz de detectar esto y tomar el control de la dirección IP virtual, lo que significa que sus clientes solo necesitan tener .1 configurado como su puerta de enlace y usted está listo para comenzar.
En términos de diseño de enrutamiento, eso dependen en gran medida de la configuración actual. Es posible que ambas puertas de enlace conduzcan al mismo borde de Internet, en cuyo caso es posible que no tenga ningún problema. El enrutamiento asimétrico puede ser malo, principalmente porque corre el riesgo de que los paquetes se entreguen en el orden incorrecto, pero nuevamente, depende en gran medida de la topología estás hablando.
Muchos principios de diseño implícitos en lo que acabo de decir. Le sugiero que investigue ambos protocolos y determine cuál es el mejor para su entorno. Si está utilizando equipos de Cisco, HSRP es un método ampliamente utilizado y bien entendido para resolver este problema.
Comentarios
- y no ‘ t olvides que también hay GLBP que hace lo mismo HSRP / VRRP (bueno, un poco) pero permite ambos pasarelas para equilibrar la carga del tráfico. Simplemente se vuelve un poco más difícil de depurar a veces ya que algunos clientes pueden estar en R1 y otros pueden estar en R2
- @mierdin, el enrutamiento asimétrico no tiene nada que ver con el reordenamiento de paquetes … el reordenamiento normalmente viene como el resultado de rutas multirrutas para el mismo prefijo …
Respuesta
Toda Internet se basa en enrutamiento asimétrico , por lo que es muy común. Los clientes están interesados en la interfaz en la que reciben el paquete y la fuente del paquete, no en qué enrutador se lo pasó en esa interfaz.
Sin embargo, el enrutamiento asimétrico puede ser problemático cuando los dispositivos que realizan un seguimiento del estado (especialmente los firewalls) y NAT están involucrados, pero por lo que puedo decir, este no es el caso en su ejemplo.
Comentarios
- También podría ser un problema cuando está ejecutando algún tipo de reenvío de ruta inversa. De lo contrario, no es un problema tan grande.
- ¿Por qué sería un problema? La ruta existe y coincide con las interfaces, por lo que incluso un RPF estricto no ‘ t se activará aquí.
- si un enrutador tiene dos interfaces externas con paquetes que salen en una dirección ( siguiendo IGP) y volviendo a otro, dejaría caer ese paquete. El paquete entrante fallaría en una estricta verificación de RPF, a menos que, por supuesto, los costos sean iguales
Responder
Clientes de red identificar los flujos de tráfico en función de la combinación de 4 valores:
- Dirección de origen
- Puerto de origen
- Dirección de destino
- Puerto de destino
Para cada conexión diferente, los 4 valores anteriores forman una combinación diferente que se usa para hacer coincidir los paquetes de respuesta con el flujo correcto.Como puede ver, la puerta de enlace o la dirección del siguiente salto no está incluida en la lista y, por lo tanto, al cliente no le importará si un paquete regresa a través de la misma puerta de enlace que utilizó para enviar sus paquetes. Por lo tanto, a los clientes de la red no les importa el enrutamiento asimétrico tan pronto como puedan recibir el tráfico del extremo remoto. En realidad, TCP / IP se diseñó originalmente para admitir enrutamiento asimétrico.
Sin embargo, si nos enfocamos en dispositivos intermedios de red, el enrutamiento asimétrico no se tolera tan pronto como esté utilizando cualquier dispositivo / tecnología que necesite ver todos los paquetes en una conexión para proporcionar una funcionalidad determinada. Por ejemplo: NAT, firewalls con estado o algunos optimizadores de WAN. El enrutamiento asimétrico en tal escenario causaría que no se proporcionara la funcionalidad deseada o, peor aún, que los paquetes se cayeran haciendo imposible la comunicación.
Respuesta
Estoy de acuerdo con las respuestas que tengo ante mí, pero tengo que agregar algo: si hay algún filtrado en cualquiera de las puertas de enlace, o en cualquier salto que se pase a través de solo 1 de las 2 puertas de enlace, es probable que surjan problemas. (los saltos que se pasan a través de ambas puertas de enlace, como la máquina de origen, la máquina de destino y cualquier salto «común a ambas rutas de puerta de enlace», no están relacionados con los siguientes escenarios)
Por ejemplo, si A enviar paquetes a B a través de la puerta de enlace1, y los paquetes regresan a través de la puerta de enlace2, entonces es muy probable que el paquete de respuesta se descarte si la puerta de enlace2 está filtrando (porque esa puerta de enlace no vio el paquete de conexión de inicio, por lo que no espera una respuesta , por lo tanto, si el destino / puerto del paquete de respuesta generalmente se filtra, se filtrará.)
(Hay, por supuesto, muchos escenarios similares)
Respuesta
Otras dos áreas donde las rutas asimétricas causarán problemas son las siguientes: 1. Descubrimiento de MTU: si la MTU más pequeña de las dos rutas difiere, el descubrimiento de ruta de MTU de punto final podría dan como resultado la mayor de las dos MTU, que a su vez provocará la caída de paquetes de tamaño máximo. Por ejemplo, si una ruta pasa por un túnel VPN y la otra no, el túnel VPN tendrá una MTU más pequeña. ping funcionará bien, pero la transferencia de archivos grandes fallará constantemente. 2. La resolución de problemas de conectividad será más difícil si uno de los dos caminos está roto pero el otro no. El buen viejo «traceroute» no será de ninguna ayuda, ya que no podrá detectar los puntos intermedios del trayecto inverso, a menos que se ejerza desde ambos lados de la conexión, lo que requiere un canal de gestión fuera de banda …