cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
16508
Visitas
49
ÚTIL
22
Respuestas

Control de rutas a través de BGP

Cisco Moderador
Community Manager
Community Manager

con Ricardo Prado


Lea la biografíaBienvenidos a la conversación en el CSC en Español. Esta es su oportunidad de aprender y hacer todas las preguntas que tenga acerca de Control de rutas a través de BGP.

Ricardo Prado es ingeniero veterano de Soporte de Cisco Latinoamérica especializado en tecnologías de routing y switching. Estudió Ingenieria en Telecomunicaciones en la Universidad Nacional Autónoma de México (UNAM) y tiene varias certificaciones de Cisco incluyendo CCNA, CCNP, CCIP, y CCIE en Routing and Switching (# 21161). Ricardo ha estado trabajando en Cisco desde el 2004, y desde hace 6 años ha estado en el grupo de High-Touch Technical Support.

Por favor use las estrellas para calificar las respuestas y así informar a Ricardo que usted ha recibido una respuesta adecuada.

Puede ser que Ricardo no pueda responder cada una de las preguntas debido la cantidad que anticipamos para este evento. Recuerde que usted puede preguntar o seguir haciendo preguntas en la comunidad de Routing & Switching.

La presentación del evento se encuentra aquí. Puede accesar el video de la sesión en vivo, aquí. En este documento Q&A encontrará todas las preguntas realizadas.

Este evento está abierto desde el 31 de enero hasta el 10 de febrero. Visite esta conversación seguido para ver las respuestas a sus preguntas.

22 RESPUESTAS 22

Hola Ricardo,

Muy buena presentación la que diste el lunes, quiero aprovecho este evento para hacerte unas preguntas:

  • ¿Cómo afecta la configuración de BGP synchronization para mis filtros?
  • ¿Puedo usar comunidades de BGP para filtrar rutas? De ser posible, me puedes compartir algunas referencias que me puedan ayudar.

De antemano gracias.

Saludos,

Juan Carlos

Hola Juan Carlos:

   Gracias por tu comentario. Contestando a tus preguntas:

* La regla de sincronización para BGP nos indica que cuando estamos aprendiendo rutas a través de iBGP no podemos advertirlas a un vecino de eBGP a menos que conozcamos esas rutas por medio de nuestro protocolo interno (RIP, EIGRP, OSPF, ISIS, rutas estáticas). Esto es con el fin de asegurarnos que exista conectividad a través de nuestro propio sistema autónomo. En las últimas versiones de BGP, esta opción está deshabilitada por lo que en esta situación no afecta la operación de los filtros. Si la sincronización está activada y no cumplimos la regla de conectividad a través del sistema autónomo local, las rutas no se advertirían a vecinos externos y por lo tanto nuestros filtros no tendrían información para trabajar.

* Las comunidades son atributos que podemos agregar a las rutas de BGP con el fin de ponerles una especie de identificador. Basados en este identificador y a través de route-maps podemos seleccionar este tipo de rutas especiales y filtrarlas o modificar sus parámetros a nuestro gusto. Existen además 4 comunidades por defecto en BGP que por sí solas realizan una especie de filtrado, estas son:

          - Internet.- Es la comunidad por defecto para todas las rutas manejadas por BGP y le indican a los equipos que dichas rutas pueden ser intercambiadas con todos los vecinos de BGP.

          - No-advertise.- Como su nombre lo indica una ruta que presente esta comunidad como atributo no puede ser advertida a ningún vecino de BGP.

          - No-export.- Las rutas de BGP que presentan esta comunidad no pueden ser advertidas afuera de el sistema autónomo local. Es decir, se pueden advertir a vecinos de iBGP pero no a vecinos de eBGP.

          - Local-as.- Son rutas que presentan el mismo comportamiento que las catalogadas por "no-export", pero dentro de una configuración de confederaciones para iBGP. Advertimos las rutas sólo a vecinos dentro de la misma sub-confederación pero no a vecinos de distinta confederación.

   Saludos,

Ricardo.

Ricardo,

Agradezco mucho tu respuesta, me ha sido de mucha ayuda.

Saludos,

Juan Carlos

Dani Ma
Level 1
Level 1

Hola Ricardo,

Tuve la oportunidad de ver el pasado webcast y me pareció muy buena la explicación que diste sobre propagación condicional, te comento que recientemente he tratado de utilizar esta opción para controlar la propagación de prefijos en mi backup BGP router, lamentablemente este es el mismo router que utilizamos como backup para las conexiones de MPLS. Así que pensé en la creación de un VRF para posteriormente configurar BGP en el VRF, hasta este punto todo funciona muy bien pero cuando trato agregar la configuración de propagación condicional para anunciar mis prefijos cuando mi conexión primaria a internet cae no puedo hacerlo.

Me gustaría saber si esto es posible o si existe otra manera de poder hacerlo.

Ojala me puedas dar tu opinión al respecto.

Saludos,

Daniel M.

Hola Daniel:

   Gracias por tus comentarios. Lamentablemente la opción de propagación condicionada de rutas no está soportada en VRF's. Esto está documentado en el siguiente bug:

CSCdy85758 - Advertise-map cannot be configured under VPN addr-family

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdy85758

   Ahora bien, el bug documenta que no hay otra manera de implementarlo, pero es probable que se pueda configurar algo semejante con EEM (Embedded Event Manager). Esta herramienta permite hacer cambios en la configuración de manera dinámica (script) al ir sensando ciertos valores en los procesos del router.

http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6815/config_guide_eem_configuration_for_cisco_integrated_services_router_platforms.html

   Por ejemplo, podrías basar este script en un track. Si estamos sensando la ruta 70.0.0.0 (como en mi ejemplo de la semana pasada), podemos configurar el siguiente track:

track 123 ip route 70.0.0.0 255.255.255.0 reachability

Esta configuración verifica que la ruta 70.0.0.0/24 esté presente en la tabla de ruteo, el track estaría en estado DOWN si la ruta no existe. Basado en el estado de este elemento podemos hacer el siguiente script:

event manager applet WITHDRAW

event track 123 state up

action 1.0 cli command "enable"

action 2.0 cli command "config t"

action 3.0 cli command "router bgp 2"

action 4.0 cli command "neighbor 1.1.1.1 prefix-list NO_LOCAL out"

action 5.0 cli command "end"

action 6.0 cli command "clear ip bgp 1.1.1.1 soft out"

event manager applet ADVERTISE

event track 123 state down

action 1.0 cli command "enable"

action 2.0 cli command "config t"

action 3.0 cli command "router bgp 2"

action 4.0 cli command "neighbor 1.1.1.1 prefix-list LOCAL out"

action 5.0 cli command "end"

action 6.0 cli command "clear ip bgp 1.1.1.1 soft out"

   Con este ejemplo, cuando el track esté en estado UP (la ruta es conocida), EEM aplica un filtro a un vecino evitando advertir las redes locales (prefix-list NO_LOCAL). Cuando el track esté en estado DOWN (la ruta ya no es conocida), EEM aplica un filtro distinto para permitir que las redes locales se adviertan (prefix-list LOCAL). El mismo script manda una actualización de la tabla de BGP al vecino para que éste empiece a recibir la actualización.

   Por supuesto, este ejemplo es muy básico y depende de qué tecnologías estén soportadas en tu equipo (EEM, tracking). EEM es una herramienta muy poderosa y se pueden hacer muchas otras cosas así que te invito a que revises el siguiente foro en caso de que prefieras hacer un script diferente al que escribí aquí:

https://supportforums.cisco.com/community/netpro/private/pilot/eem

   Saludos,

Ricardo.

Ricardo,

Muchas gracias por tu respuesta y por el script que me proporcionas, me será de mucha ayuda para la implementación que estoy haciendo.

Saludos,

Daniel

Hola,

No se si este sea el foro correcto pero tengo una duda sobre BGP, como puedo modificar la forma en la que mi trafico sale o entra a mi red con los atributos de bgp?

Chris

Hola Chris,

   Por supuesto que es el foro correcto. Con BGP podemos influenciar la manera en que el tráfico de nuestra red salga o lleugue de manera distinta. Por regla general, nosotros sólo tenemos posiblidad de hacer cambios a BGP en nuestro router local, así que los siguientes atributos nos permiten modificar el comportamiento del tráfico:

TRAFICO ENTRANTE

  * AS-PATH

  * MED

TRAFICO SALIENTE

  * WEIGHT

  * LOCAL PREFERENCE

   Para el tráfico que mandamos desde la red local hacia Internet, podemos darle preferencia a las rutas aprendidas por un cierto enlace (un enlace con más ancho de banda o con mayor estabilidad). Esto lo podemos hacer con el atributo de Weight o bien Local Preference. Para estos dos atributos el valor más alto siempre es preferido y el valor por defecto es 0 para Weight y 100 para Local Preference.

   Para el tráfico que recibimos desde Internet, podemos sugerir a los equipos remotos que usen una ruta que entregue el tráfico en el enlace que queramos (un enlace con menos utilización o más ancho de banda y estabilidad). Los atributos MED y AS-PATH nos permiten hacer esto. En el caso de MED, recordemos que este atributo es NON-TRANSITIVE, es decir que es un atributo que no se va propagando entre diferentes sistemas autónomos (a menos que cada sistema autónomo se configure para hacerlo y casi nunca es el caso), por lo que este atributo no sería recomendado de utilizar. Para el AS-Path, hay que recordar que mientras más sistemas autónomos estén contenidos en esta lista la ruta será menos preferida, de esta manera podemos agregar muchas veces nuestro propio sistema autónomo a través de un enlace para forzar a que los equipos remotos no prefieran este puerto para llegar a nuestra red (AS-Path sólo revisa cuántos sistemas autónomos hay contenidos en la lista, no revisa si están repetidos o no). Este parámetro se puede modificar con un route-map:

route-map SETPREPEND permit 10

set as-path prepend

   Saludos,

Ricardo.

Hola Ricardo,

Gracias por tu explicación, sobre el filtrado para trafico saliente serias tan amable en mencionarme cual es la diferencia entre el comando local-as y el local-as no-prepend. He tratado ver la diferencia utilizando ambos comando en el laboratorio pero no he podido identificarla.

Saludos,

Chris

Hola Chris:

   Los comandos que mencionas se utilizan generalmente cuando se está en el proceso de migración de un sistema autónomo a otro. El comando de "local-as" permite a tu equipo establecer una adyacencia de BGP pero utilizando un sistema autónomo diferente del que tienes configurado en tu proceso de BGP. Por ejemplo, asumamos que tienes la siguiente configuración:

router bgp 100

neighbor 12.12.12.2 remote-as 200

neighbor 12.12.12.2 local-as 500

neighbor 13.13.13.3 remote-as 300

    Con esta configuración, tu vecindad con el equipo 13.13.13.3 se establece utilizando el sistema autónomo 100, mientras que tu vecindad con el equipo 12.12.12.2 se levanta con el sistema autónomo 500  (12.12.12.2 utiliza en su comando de "neighbor" la opción "remote-as 500").

   Estas configuraciones son válidas únicamente para vecinos de eBGP.

   Ahora bien, cuando tu router envíe actualizaciones al vecino 13.13.13.3 que provengan del equipo 12.12.12.2, con esta configuración, el atributo de AS-PATH va a contener los dos sistemas autónomos configurados en tu equipo: 100 y 500. Aquí un ejemplo:

 

300#s ip bgp
BGP table version is 7, local router ID is 30.30.30.30
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 20.20.20.0/24    13.13.13.1                             0 100 500 200 i       <<<<<<<<

   Como puedes ver tu equipo está anteponiendo el sistema autónomo "falso" (500) a sus actualizaciones de eBGP. Si por el contrario, por tu diseño no quieres que esto suceda así, puedes usar la opción de "no-prepend" y ahora las actualizaciones van a remover el número 500 del AS-PATH, como en el ejemplo:

router bgp 100

neighbor 12.12.12.2 remote-as 200

neighbor 12.12.12.2 local-as 500 no-prepend

neighbor 13.13.13.3 remote-as 300

   Y la tabla de BGP en el vecino 13.13.13.3 sería la siguiente:

300#s ip bgp
BGP table version is 11, local router ID is 30.30.30.30
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 20.20.20.0/24    13.13.13.1                             0 100 200 i      <<<<<<<

   Cabe resaltar que como práctica recomendada, la utilización de estos comandos sólo debe ser utilizada durante el periodo de transición de moverse de un sistema autónomo a otro (temporal).

   Saludos,

   Ricardo.

Gente:

 

Buenas tardes,  me surgió una duda. Supongamos una topología como la de abajo, donde tengo un router Cisco3650 que levanta BGP contra 3 proveedores (ISP I, ISP2, ISP3) Solo el isp2 nos envia la full table, los demas solo manda la default (0.0.0.0).  Tengo una pc Cliente con la ip 100.100.177.10/24 con gw 10.100.177.1 (que es una interface Vlan en el router). Tengo hecho route-maps para todos los proveedores para controlar la salida y la entrada. Por ejemplo en el ISP2 matcheo el AS y aplico un local preference de 300. Con esto el cliente cuando quiere ir a una red conocida (por ejemplo 8.8.8.8) por los 3 isp, prefiere al ISP2. 

El problema se me presenta en lo siguiente. Tengo hecho un route-map que matchea la red 100.100.177.0/24  y le aplica un set ip default next-hop a la 10.10.10.1 (suponiendo que el neigbhor del as1 sea 10.10.10.1  y la del lado de mi router la 10.10.10.2).  Yo entiendo que con el atributo "set ip default next-hop " aplicado en el route-map deberia obligar a los destinos que no existan en la tabla de enrutamiento a que salga por ese next-hop. Esto es asi? Porque el problema que tengo es que por ejemplo la red 8.8.8.8 la conozco por bgp, pero cuando aplico el route-map en la interface vlan (ip policy route-map)  me obliga todas las rutas por ese next-hop, inclusive por ejemplo la 8.8.8.8 que la conozco por BGP y que tiene un local-pref de 300. Porque puede ser que no funcione?

 

Tengo entendido que si aplico el ip next-hop  (sin el default; si debería obligar las rutas a ese next-hop) pero con el default debería obligar solo si no tengo la red en la tabla de ruteo. Es así?

 

Ejemplo_BGP.png

 

 

Gracias,

Saludos,

Damian

Hola

Con el route-map es recomendable ser especifico con el trafico que coincidi, Yo usualmente utilizo ACL extendidas y veo la secuencia que usara el set ip next hop. Es posible compartir la configuracion del route-map?

Gracias 

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

El route-map sería:

show route-map in_internet_isp1
route-map in_internet_isp, permit, sequence 10
Match clauses:
ip address (access-lists): redes_lan
Set clauses:
ip default next-hop 10.10.10.1


show ip access-lists redes_lan
Extended IP access list redes_lan
10 permit ip 10.100.177.0 0.0.0.255 any


Luego lo aplico a la interface vlan xxx con el comando:

ip policy route-map in_internet_isp1


Con esto lo que quiero lograr es que si la red existe por ejemplo la 8.8.8.8 no le haga caso al routemap y me lo saque por el otro isp que la propaga (que le puse el localpref de 300), y que si quiero ir a hotmail (que ningun proveedor me da el prefijo) elija la 10.10.10.1

Gracias,
Saludos
Damian

Muchas gracias Damian, comprendo la situacion.

Tambien consultar si tu router de borde esta advirtiendo la red de la computadora a los 3 proveedores.

 

Gracias. 




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<
Vamos a comenzar

¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.

Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco: