01-30-2012 11:46 AM - editado 03-21-2019 04:40 PM
con Ricardo Prado
Bienvenidos 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.
el 02-02-2012 01:51 PM
Hola Ricardo,
Muy buena presentación la que diste el lunes, quiero aprovecho este evento para hacerte unas preguntas:
De antemano gracias.
Saludos,
Juan Carlos
el 02-03-2012 09:06 AM
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.
el 02-03-2012 11:46 AM
Ricardo,
Agradezco mucho tu respuesta, me ha sido de mucha ayuda.
Saludos,
Juan Carlos
el 02-03-2012 12:21 PM
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.
el 02-05-2012 01:16 PM
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:
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
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.
el 02-07-2012 09:46 AM
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
el 02-05-2012 09:20 AM
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
el 02-05-2012 01:26 PM
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.
el 02-08-2012 08:59 AM
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
el 02-09-2012 04:36 PM
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.
el 10-17-2017 12:53 PM
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í?
Gracias,
Saludos,
Damian
el 10-17-2017 02:39 PM
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
:-)
el 10-17-2017 03:35 PM
10-17-2017 03:48 PM - editado 10-17-2017 03:54 PM
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.
Descubra y salve sus notas favoritas. Vuelva a encontrar las respuestas de los expertos, guías paso a paso, temas recientes y mucho más.
¿Es nuevo por aquí? Empiece con estos tips. Cómo usar la comunidad Guía para nuevos miembros
Navegue y encuentre contenido personalizado de la comunidad