Redireccionar el tráfico entrante a otro enrutador que no ejecuta BGP

7

Personas,

Tengo dos enrutadores en el núcleo de mi ISP. El primero de ellos es un equipo Cisco un poco viejo, que es donde tengo sesiones de eBGP con mis upstream, IX y downstream. El segundo es un MikroTik CCR, que actúa como servidor DHCP, firewall, etc. para mis clientes.

Debido al aumento de nuestra red, el antiguo enrutador Cisco no puede manejar todo el tráfico actual de manera fluida, pero por razones internas no podemos cambiarlo a otro equipo por ahora.

Estoy considerando redirigir todo el tráfico entrante directamente al equipo MikroTik, de tal manera que Cisco no necesite enrutarlo. Pero no estoy seguro de que sea posible.

Utilizo un rango / 29 con cada uno de mis canales ascendentes, por lo que puedo hacer que el enrutador MikroTik se aborde dentro del mismo rango que mis enrutadores fronterizos y los de mi canal ascendente. Ex.:

  • Primer enrutador de Upstream: 198.51.100.1/29
  • Segundo enrutador de Upstream: 198.51.100.2/29
  • Mi enrutador Cisco: 198.51.100.6/29
  • Mi enrutador MikroTik: 198.51.100.5/29

Diagrama de red - núcleo

192.0.2.1 es la puerta de enlace predeterminada para el enrutador MikroTik (192.0.2.2).

Sería fácil resolver esto utilizando el prependiente as-path si el equipo MikroTik estaba ejecutando BGP, pero no lo es y no puede serlo por razones técnicas y comerciales.

Pensé que la redirección podría hacerse cambiando el atributo BGP next-hop de los prefijos anunciados a la dirección IP del enrutador MikroTik, de la siguiente manera (de conformidad con el diagrama de red anterior):

route-map CHANGE_NEXTHOP permit 10
 set ip next-hop 198.51.100.5
!
router bgp XXXXXX
 neighbor 198.51.100.1 route-map CHANGE_NEXTHOP out
 neighbor 198.51.100.2 route-map CHANGE_NEXTHOP out
!

De esa manera, el tráfico de carga fluiría a través de la conexión directa entre ambos enrutadores, mientras que el tráfico de descarga fluiría directamente desde el flujo ascendente al enrutador MikroTik.

Sin embargo, leí en alguna parte que esto solo es posible cuando las sesiones de BGP son multihop, no cuando los vecinos están directamente conectados. Además, por lo que entendí, cambiar el siguiente salto es una característica única de iBGP.

Estoy lejos de ser un experto de Cisco y busqué mucho, pero no encontré una respuesta concluyente a mis dudas, por lo que alguien podría decirme si es posible hacer lo que describí en la configuración anterior. fragmento o sugerir alguna solución a mi difícil situación?

Desafortunadamente, actualmente no tengo formas de ejecutarlo en un laboratorio (incluso usando máquinas virtuales) para probar si funciona según lo previsto.

Estaré agradecido por esto y cualquier otra información que proporcionen.

routing bgp Tiago.SR
fuente
Tal vez estoy malinterpretando lo que está tratando de lograr, pero ¿cómo la configuración de lo que describe le ayudará a no necesitar hacer eBGP en ese enrutador Cisco? Un diagrama de red puede ayudar mucho aquí, pero lo que está haciendo aquí no funcionará como pretende. Además, ¿qué es 192.51.100.5?
Teun Vink
¿Están todos conectados al mismo segmento y ejecuta algún protocolo de enrutamiento interno entre el enrutador Cisco y el dispositivo MikroTik? También sería útil saber si este es un segmento de Ethernet o algo más. El comportamiento predeterminado para ethernet parece ser no cambiar la dirección anunciada del siguiente salto cuando se anuncia en el mismo segmento que la dirección del siguiente salto. Probé esto en un pequeño laboratorio con 4 enrutadores conectados por un conmutador y en el enrutador Cisco utilicé una ruta estática que apuntaba a MikroTik como el siguiente salto para las redes conectadas y las rutas anunciadas obtuvieron MikroTik como el siguiente salto automáticamente.
Jimmy
@TeunVink Necesito mantener eBGP en el enrutador Cisco, pero ya no puede manejar todo nuestro tráfico de red actual. No hay 192.51.100.5 ... pero 198.51.100.5 es mi enrutador MikroTik, como se describe.
Tiago.SR
El enrutador @Jimmy Cisco está conectado directamente a mis circuitos dedicados con las descargas. El enrutador MikroTik se puede agregar al mismo segmento Ethernet mediante VLAN y puente, convirtiéndose en el 198.51.100.5. Es ethernet. Estoy tratando de cambiar este comportamiento predeterminado configurando manualmente el siguiente salto a la dirección IP del enrutador MikroTik usando set ip next-hop...Cisco. Dibujaré un diagrama de red y actualizaré la publicación original lo antes posible.
Tiago.SR
1
La modificación del siguiente salto de AFAIK se puede utilizar para equilibrar el tráfico de la manera descrita. En general, debe funcionar, al menos desde el punto de vista de Mikrotik, pero depende de la configuración del enrutador ascendente. Por ejemplo, los filtros en sentido ascendente pueden prohibir tales anuncios.
mmv-ru

Respuestas:

1

Puede haber una manera de lograr esto explotando la siguiente regla BGP del siguiente salto:

Desde RFC 4271, 5.1.3 NEXT_HOP:

Al enviar un mensaje a un par externo, X, y el par está a un salto de IP del altavoz:

- Si la ruta que se anunció se aprendió de un par interno o se origina localmente, el hablante BGP puede usar una dirección de interfaz del enrutador par interno (o el enrutador interno) a través del cual la red anunciada es accesible para el parlante para el atributo NEXT_HOP , siempre que el par X comparta una subred común con esta dirección. Esta es una forma de atributo NEXT_HOP "de terceros".

¿Podrías probar esto?

  • Elimine la adyacencia OSPF entre Cisco y Mikrotik en la red 192.168.2.0/30

  • Cree la adyacencia OSPF entre los enrutadores Cisco y Mikrotik a través de la red compartida 198.51.100.0/29

  • Asegúrese de que las rutas que el enrutador Cisco está aprendiendo a través de OSPF tengan un próximo salto de 198.51.100.5

  • Borra las sesiones de BGP. El enrutador Cisco ahora debería anunciar rutas a subredes internas con un BGP NEXT_HOP de 198.51.100.5

Este artículo muestra un ejemplo:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

BGP Next Hop (redes de acceso múltiple)

ingrese la descripción de la imagen aquí

Este ejemplo muestra cómo se comporta el siguiente salto en una red de acceso múltiple como Ethernet.

Suponga que RTC y RTD en AS300 ejecutan OSPF. RTC ejecuta BGP con RTA. RTC puede llegar a la red 180.20.0.0 a través de 170.10.20.3. Cuando RTC envía una actualización de BGP a RTA con respecto a 180.20.0.0, RTC utiliza como próximo salto 170.10.20.3. RTC no utiliza su propia dirección IP, 170.10.20.2. RTC usa esta dirección porque la red entre RTA, RTC y RTD es una red de acceso múltiple. El uso RTA de RTD como próximo salto para alcanzar 180.20.0.0 es más sensato que el salto adicional a través de RTC. Nota: RTC anuncia 180.20.0.0 a RTA con un próximo salto 170.10.20.3. Si el medio común para RTA, RTC y RTD no es de acceso múltiple, sino NBMA, se producen complicaciones adicionales.

Karl Billington
fuente
0

Supongo que desea afectar el tráfico de Internet INBOUND y sabe cómo manejar su tráfico OUTBOUND.

Entonces, la forma más fácil de lograr esto sería hacer " pre- pendiente de ruta " en su enrutador Cisco cuando se anuncia en su flujo ascendente. Entonces, su tráfico de internet INBOUND definitivamente tomaría el camino más corto hacia usted, que será a través del enrutador MikroTik.

Para ver un ejemplo, mira esto .

Mo Moghaddas
fuente
Gracias, casi lo entendiste, excepto que el equipo MikroTik no está ejecutando BGP y no es posible cambiar esto. Es principalmente debido a este detalle que no consigo obtener una solución a este problema.
Tiago.SR
Si bien el antecedente de AS-PATH se cita comúnmente como una solución para dirigir el tráfico a un enrutador BGP específico, no es muy eficiente, muchos de los que se encuentran en sentido ascendente se niegan a propagar prefijos con más de 3 ocurrencias del número AS, y parte del tráfico seguirá siendo el " enrutador de respaldo ".
JFL
@JFL eso no es del todo cierto: AS Path pre-pendiente es una forma perfectamente válida de desreferenciar el tráfico entrante. El único tráfico que no afectará es el del AS ascendente directamente conectado y sus clientes: la mayoría de las veces usarán la preferencia local internamente para enviarle tráfico a través de su enlace, en lugar de otro AS
Benjamin Dale
0

Cree una dirección vrrp para cisco y mikrotik y conviértala en la puerta de enlace predeterminada del conmutador central. Establezca el mikrotik como el miembro de mayor prioridad.

El mikrotik debe tener una ruta predeterminada recibida del enrutador Cisco y una de "mi red", prefiriendo "mi red" como la ruta preferencial. Esto puede ser a través de OSPF o estáticamente asignado.

Tenga una sonda IP SLA desde microtik o cisco para verificar la conectividad ascendente a "mi red". Si hay un problema aguas arriba, reduzca la prioridad de vrrp en el enrutador mikrotik para que el tráfico salga a través de Cisco.

En la configuración, tendrá redundancia y no tendrá ningún problema con el tráfico entrante a través de Cisco, suponiendo que esté generando tráfico entrante en Cisco. El tráfico entrante y saliente tomará diferentes caminos.

MFT
fuente