el 12-11-2023 07:28 AM
PREGUNTA: Hola a todos buen dia, tengo una duda respecto al protocolo BGP, espero puedan ayudarme.
Actualmente tengo un CORE que maneja 3 neighbors adyacentes, (MPLS (1) , VIPTELA (2), NUEVO SDWAN(3)). Las multiples redes de la compañia actualmente se manejan con el neighbor 1 y el neighbor 2, y son enseñadas al CORE, como deberia funcionar.
Estamos realizando un proceso de migracion del antiguo viptela hacia el nuevo SDWAN, por lo que se estan migrando algunas sedes pequeñas (redes pequeñas) de la compañia, requerimos que las nuevas redes que tiene el nuevo SDWAN sean enseñadas al core de forma normal, pero estas no sean enseñadas por parte del CORE hacia los neighbors (1) y (2). Actualmente lo venimos manejando desde el CORE con dos filtros donde indicamos las redes que no queremos anunciar hacia estos neighbors 1 y 2, y asi lo denegamos. La pregunta es, puedo hacer esto de forma general sin estar agregando cada sub red a estos filtros? ya que se me va volver una lista larguisima en los prefixlist. Gracias
¡Resuelto! Ir a solución.
el 12-11-2023 09:40 AM
Te voy a enviar un ejemplo basico para que tengas la idea, usando las comunidades en BGP:
Son 3 router, el R2 hace de Core, las rutas recibidas por el R1 les asigna una community en BGP y luego lo que hace es antes de enviarle las rutas al vecino R3 pues verifica que no esten en la community list indicada y en ese caso las deniega.
Con este sistema no tienes que estar agregando manualmente las rutas a un prefix-list, es solo cuestion de planificarlo bien y no vas a tener problemas.
Espero que te sea de ayuda.
router bgp 65002
bgp log-neighbor-changes
neighbor 10.0.1.2 remote-as 65000
neighbor 10.0.1.2 route-map BGP-IN in
neighbor 10.0.2.2 remote-as 65003
neighbor 10.0.2.2 send-community
neighbor 10.0.2.2 route-map BGP-OUT out
-----
route-map BGP-OUT deny 10
match community 1
!
route-map BGP-IN permit 10
set community 65000
ip community-list 1 deny 65000
----
Fijate que al verificar la ruta aprendida por BGP te muestra la comunidad:
R2#sh ip bgp 192.168.0.0
BGP routing table entry for 192.168.0.0/24, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 3
65000
10.0.1.2 from 10.0.1.2 (192.168.0.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 65000
rx pathid: 0, tx pathid: 0x0
Saludos
el 12-11-2023 08:20 AM
Hola,
Una de las opciones que tienes es marcar las rutas aprendidas por el SDWAN en el Core y crear un Route-Map que deniegue las rutas tageadas hacia los vecinos 1 y 2.
Saludos.
el 12-11-2023 08:42 AM
Hola Jose, gracias por responder y por el consejo.
De hecho actualmente lo tengo asi, tengo un route map hacia unos prefix list que apuntan hacia los neighbors 1 y 2, alli coloco las redes que me enseña el SDWAN y simplemente le digo que deniegue esos segmentos hacia estos vecinos (hasta el momento lo he aplicado con 4 redes que hemos migrado). El problema es que como son tantas subredes, queria saber si hay alguna forma de establecer que el neighbor 3 que es el SDWAN no enseñe nada a los otros, es decir solo se quede en el core. Ya que sera tedioso cuando se migren la totalidad de sedes (aprox 700 segmentos). Gracias
el 12-11-2023 09:40 AM
Te voy a enviar un ejemplo basico para que tengas la idea, usando las comunidades en BGP:
Son 3 router, el R2 hace de Core, las rutas recibidas por el R1 les asigna una community en BGP y luego lo que hace es antes de enviarle las rutas al vecino R3 pues verifica que no esten en la community list indicada y en ese caso las deniega.
Con este sistema no tienes que estar agregando manualmente las rutas a un prefix-list, es solo cuestion de planificarlo bien y no vas a tener problemas.
Espero que te sea de ayuda.
router bgp 65002
bgp log-neighbor-changes
neighbor 10.0.1.2 remote-as 65000
neighbor 10.0.1.2 route-map BGP-IN in
neighbor 10.0.2.2 remote-as 65003
neighbor 10.0.2.2 send-community
neighbor 10.0.2.2 route-map BGP-OUT out
-----
route-map BGP-OUT deny 10
match community 1
!
route-map BGP-IN permit 10
set community 65000
ip community-list 1 deny 65000
----
Fijate que al verificar la ruta aprendida por BGP te muestra la comunidad:
R2#sh ip bgp 192.168.0.0
BGP routing table entry for 192.168.0.0/24, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 3
65000
10.0.1.2 from 10.0.1.2 (192.168.0.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 65000
rx pathid: 0, tx pathid: 0x0
Saludos
el 12-12-2023 08:12 AM
Gracias por la ayuda Jose, voy a aplicarlo, la única duda que me queda es (usando el ejemplo que das), al momento de usar el route map IN con el R1 vuelvo a darle el mismo AS que ya habia nombrado antes?:
neighbor 10.0.1.2 remote-as 65000
neighbor 10.0.1.2 route-map BGP-IN in
route-map BGP-IN permit 10
set community 65000
Muchas gracias
el 12-12-2023 10:37 AM
Pues normalmente puedes usar el formato AS:NN, no es obligatorio pero si recomendado.
Para ampliar un poco más el ejemplo:
ip bgp-community new-format.
neighbor 10.0.2.2 send-community Both
route-map BGP-IN permit 10
set community 65000:111
Espero que te sea de ayuda y recuerda que esto es solo orientativo y tienes que adaptarlo según tus necesidades y perdona pero estoy respondiendo desde el movil.
Saludos
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