Mejor Enterprise Multihoming


33

Me gustaría obtener algunas opiniones sobre las formas en que puedo mejorar un diseño de doble enrutador y doble proveedor de BGP. Cada proveedor proporciona una subred pública / 24. Me referiré a los enrutadores, circuitos, subredes, grupos HSRP y proveedores como A y B, respectivamente. El ancho de banda en cada circuito es adecuado para toda la carga.

Diseño actual

El diseño actual intenta lograr la simetría por proveedor. En un estado estable, la lógica de enrutamiento prevista es que el tráfico hacia / desde la subred A solo transita por el circuito A y el tráfico hacia / desde la subred B solo transita por el circuito B. Los circuitos se respaldarían entre sí en un estado fallido.

Los proveedores solo anuncian la ruta predeterminada. El enrutamiento de salida implica una mezcla de PBR y HSRP. Los enrutadores no tienen enrutamiento entre ellos: sin iBGP, sin OSPF, sin enrutamiento estático. En cambio, hay dos grupos HSRP que siguen la ruta predeterminada. El enrutador A es primario para el grupo HSRP A y el enrutador B es primario para el grupo HSRP B. Los dispositivos aguas abajo tienen una ruta predeterminada que apunta al grupo HSRP A y PBR que dirige el tráfico proveniente de la subred B al grupo B. HSRP. comunidades La subred A se antepone y se comunica en el circuito B y la subred B se antepone y se comunica en el circuito A.

Veo mucho margen de mejora en este diseño. La falta de conocimiento de la topología de Internet combinada con la afinidad del circuito elimina por completo la mejor selección de ruta. Existen preocupaciones sobre la designación de nivel de los proveedores y el diseño se ha racionalizado para proporcionar un "rendimiento aceptable" y más fácil de solucionar. De hecho, el diseño no podría ser más simple. He demostrado que el tránsito de un AS adicional agrega 6 saltos y 63 ms (+ 421%) al RTT. Preferiría no conformarme con lo aceptable.

Mejor diseño

El mejor diseño proporciona a los enrutadores el mayor conocimiento posible de la topología de Internet. Se deja el mejor algoritmo de ruta para determinar la lógica de enrutamiento entrante y saliente. Los circuitos se respaldarían entre sí en un estado fallido.

Los proveedores anuncian la vista completa. Los enrutadores ejecutan iBGP y OSPF. HSRP es eliminado. El enrutamiento de salida sería la mejor ruta basada exclusivamente en el destino y el enrutamiento de entrada se dejaría al mejor algoritmo de ruta y caprichos del proveedor de tránsito.

Ahora que lo escribo, parece más simple. Por lo menos, tomó menos palabras para explicar. Hay preocupaciones sobre la asimetría, pero he visto mucha asimetría en el diseño actual. Creo que probablemente son igualmente propensos a la asimetría y realmente no me preocupa. Nunca hemos visto problemas como resultado. Actualmente queda relegado al reino de los ifs, "¿Qué 'si' tuviéramos que solucionar algo?"

¿Estoy fuera de la base aquí o golpeé el clavo en la cabeza? ¿Cómo han resuelto otros este problema? ¿Qué haría Google?


Gran detalle y explicación. ¡Bienvenido!
Pandom

Tradicionalmente, las preguntas "Me gustaría obtener algunas opiniones sobre mi diseño" no son realmente buenas preguntas SE ... Pero esto se puede discutir en meta
Aaron

Respuestas:


16

Sí, golpeaste el clavo en la cabeza.

Obtendrá asimetría en el diseño mejorado, pero la asimetría es una realidad en Internet, y realmente no hay una buena razón para esperar un enrutamiento simétrico del tráfico hacia / desde. Dispare, todo el concepto de enrutamiento de paquetes es que los paquetes separados se enrutan independientemente uno del otro y pueden tomar diferentes caminos, incluso paquetes que van en la misma dirección.

Personalmente, detesto el PBR. Es una de esas tecnologías que cuando decido que es la mejor solución al problema, me detengo y retrocedo para ver si realmente entiendo la naturaleza real del problema, incluso de nuevo para averiguar cuál es el problema comercial que se debe resolver. es. Cuando lo hago, casi siempre encuentro que hay una manera de resolver el problema sin usar una tecnología como esa.

Tendrá que acostumbrarse a tener rutas completas de Internet en sus enrutadores, pero una vez que se acostumbre, es muy fácil de entender y solucionar problemas. Ciertamente, hay menos "partes móviles" de diferentes protocolos de los que preocuparse.

No desea tener rutas completas de Internet en su base de datos OSPF, por lo que querrá anunciar un valor predeterminado a través de OSPF en el interior de su red (o tal vez valor predeterminado estático ... personalmente prefiero el valor predeterminado en OSPF). Eso moverá el tráfico hacia los enrutadores de Internet que hablan BGP, lo que puede tomar la decisión más informada de tener las rutas completas de Internet.

Eso te dará cerca del "mejor camino basado en el destino". Todavía habrá casos en los que el tráfico hará cosas que no espera, así que querrá familiarizarse con el proceso de selección de ruta BGP.


Gracias Jeff. Estoy de acuerdo con su disposición sobre PBR. Lo he visto implementado en formas de pesadilla. He eliminado más PBR de las redes de las que me gustaría recordar. Una vez administré un entorno escalonado donde PBR se implementó como un mecanismo de enrutamiento virtual con un mapa de ruta único por SVI (100). El PBR también contenía cláusulas de permiso / no conjunto que dieron como resultado el cambio de proceso. En copia impresa, eran como 60 páginas de configuración. No hace falta decir que tomé la bola de demolición; lo reemplazó con VRF.
Dennis Olvany

6

Ofrecer un enfoque diferente a los otros ya dados, que puede o no ser mejor que las ideas existentes, pero principalmente a través de algunas ideas adicionales que existen;

Diría que dos pasos sencillos que puede seguir para mejorar su situación actual son los siguientes;

Paso 1 ;

Obtenga tablas BGP completas de ambos proveedores: ahora, tendrá un enrutamiento de salida más óptimo porque estará enrutando a través del proveedor de tránsito con la ruta AS más pequeña a su destino. Como dijo, puede eliminar HSRP y simplemente anunciar una ruta predeterminada en OSPF y ejecutar iBGP entre sus dos enrutadores de borde.

Paso 2 ;

Configure AS prepends y comunidades, etc. en sus dos enrutadores de borde para controlar el tráfico saliente de forma granular según lo requiera. Por lo tanto, el ISP B puede tener una mejor ruta hacia alguna subred, pero puede comprar más tránsito del ISP A y más bien cuando lo haga a través de ellos, y así sucesivamente.


Suponiendo que los dos / 24 que mencionó son espacio de direcciones independiente de PI, por lo que los está anunciando a través de ambos proveedores, o ambos proveedores han acordado anunciar el mismo espacio de direcciones IP para usted, ahora puede anunciar ambos prefijos a ambos ISP desde ambos enrutadores sin pretensiones o comunidades y obtenga también un mejor enrutamiento entrante (por supuesto, a menos que tenga algunos CDR a los que deba adherirse o similar, en cuyo caso puede sintonizar según sea necesario).


Gracias javano. Creo que estamos de acuerdo en que las políticas de enrutamiento entrante y saliente son perjudiciales. ¡Quiero acabar con PBR, prepending y comunidades!
Dennis Olvany

3

Comience de manera simple, luego agregue complejidad solo cuando sea necesario. Me preguntaría si incluso es necesario ejecutar OSPF en sus enrutadores de borde de Internet. Arranque PBR en la acera y úselo solo en su red interior.

  1. Tome rutas completas de Internet si su enrutador tiene memoria, ¡pero filtre! Mezcle cualquier cosa gt a / 24.
  2. Tome una ruta predeterminada desde A y B.
  3. Debe ejecutar iBGP para permitir que sus enrutadores tomen las mejores decisiones de ruta considerando todos los prefijos recibidos de A y B.
  4. Si planea utilizar A / B's / 24s con ambos proveedores, puede influir mejor en el tráfico entrante anteponiendo A's / 24 en la red de B y viceversa. ¡Ambos / 24 deben ser anunciados! Verifique con su ISP sus comunidades para establecer los preparativos para usted.
  5. Use dos grupos HSRP diferentes para su tráfico saliente desde su firewall; puede configurar ECLB para compartir la carga en sus dos enrutadores. Equilibrio de carga de igual costo .

Todo esto se puede simplificar si solo está utilizando un único / 24 anunciado tanto para A como para B.

Más adelante, busque más complejidad para una mejor ingeniería y protección del tráfico:

  1. Familiarícese con las comunidades de A y B, ya que puede preferir usar mapas de ruta de pares para configurar localpref para determinar qué rutas usan A vs. B.
  2. Establezca una ruta predeterminada estática flotante en ambos enrutadores como respaldo de emergencia para todo lo demás en caso de que su BGP explote.

    ip route 0.0.0.0 0.0.0.0 a.b.c.d 254
    
  3. Busque formas más complejas de publicidad para controlar su política de entrada, como la mitad de su espacio de IP que pasa por A y la otra mitad por B. Para un / 24 dado, puede anunciar el / 24 en A y B, pero dividirlo en dos / 25 y anunciar el / 25 inferior a A y el / 25 superior a B.

  4. Use la reconfiguración suave para poder ajustar sus políticas y hacer un restablecimiento parcial en la sesión BGP para que no disminuya sus prefijos en el otro lado si restablece completamente (o borra) la sesión. Los cambios en la política requieren un reinicio.


1

Entonces, lo que entiendo de la redacción es que realmente no es necesario tomar decisiones basadas en rutas AS para llegar a subredes externas y el único propósito de la búsqueda doble a dos ISP es comprar redundancia para llegar a Internet. Si ese es el caso, entonces realmente no necesita ejecutar BGP. Puede aceptar las mismas rutas predeterminadas que ya recibe de su proveedor de servicios. Ahora, para el lado local de la red, ejecute una sola área ospf en los enrutadores que se conectan al ISP en la interfaz que está frente a su LAN (no incluya la interfaz del ISP en el proceso) y dependiendo de lo simple que deba ser el diseño para puede agregar enrutadores en diferentes áreas y resumir las subredes en los límites de la red, pero para dos subredes, creo que el tamaño de la base de datos OSPF o el número de inundaciones LSA no es una gran preocupación,

En cada enrutador OSPF que se conecta al ISP, redistribuya las rutas predeterminadas aprendidas en OSPF utilizando una declaración de "origen de información predeterminada".

Un par de ventajas:

  1. Con este diseño, cuando crezca la red, puede habilitar BGP con los proveedores de servicios y simplemente aceptar la ruta predeterminada sin tocar nada dispositivos posteriores. Hasta que verifique que está recibiendo una ruta predeterminada de BGP, está bien.

  2. Siempre que necesite enrutar el tráfico de un ISP para mantenimiento, simplemente elimine el "origen de información predeterminada" debajo del proceso OSPF en ese enrutador y continúe con el mantenimiento. No se necesita nada más.

Y estoy de acuerdo con la respuesta anterior en que el enrutamiento simétrico está sobrevalorado, prefiero la escalabilidad y la facilidad de mantenimiento.


Si entiendo los planes de @ user161, el objetivo es una selección de ruta de salida más inteligente. ¿Cómo lo logras en tu solución basada en OSPF?
Paul Gear

Gracias Vinny. La conmutación por error del tráfico externo no es un problema, pero ¿no necesitaría BGP para la conmutación por error entrante? Si solo se trata de usuarios que obtienen PAT'd en Internet, puede ser factible, pero este es un entorno de alojamiento web.
Dennis Olvany

@ user161: Absolutamente, si necesitamos una conmutación por error entrante para sus subredes originadas, entonces necesita ejecutar BGP. Verifique con sus ISP para ver si admiten la capacidad ORF para el emparejamiento BGP, de modo que pueda anunciar subredes originadas localmente a través de BGP con un filtro entrante en los enrutadores fronterizos solo para aceptar una ruta predeterminada y / o seleccionar algunas subredes de los enrutadores ISP. Si el ISP no admite ORF, entonces realmente no hay mejores opciones que comprar un enrutador con más jugo ...
Vinny,

1

Si la tabla de BGP completa es demasiado para usted, creo que podría considerar recibir una porción. Quizás el proveedor A y B anuncian una ruta predeterminada y sus rutas AS locales. Debería ejecutar iBGP internamente. De esa forma, tendría la ruta más corta para cualquier cosa directamente conectada a los proveedores y tomaría cualquiera de las rutas AS descendentes.


Gracias Kelly. El mejor diseño correría iBGP. Una actualización de hardware está provocando la revisión de la arquitectura, por lo que no me preocupa demasiado que los enrutadores puedan manejarlo. El equipo de ventas dice que la transición de IOS a JUNOS es pan comido. No estoy tan seguro de estar de acuerdo, hasta ahora.
Dennis Olvany

No sé si diría que es un juego de niños ... es desalentador aprender, no solo la nueva sintaxis, sino el nuevo concepto de sintaxis. Sin embargo, lo que diré es que creo que vale la pena. JunOS te dejará rascándote la cabeza por un tiempo, pero en algún momento, hará clic y todo comenzará a tener sentido. Todavía tendrá que buscar cosas, por supuesto (conocer la sintaxis de un idioma no es lo mismo que conocer el vocabulario), pero en general tendrá sentido.
Jeff McAdams
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.