BGP - Conditional Advertisement

-
La función de anuncio condicional en BGP nos brinda un método para anunciar prefijos según la existencia de otros en la tabla BGP.

Resulta especialmente útil cuando gestionamos múltiples proveedores de servicios de Internet (ISP) en nuestra red. En ocasiones, la publicación de nuestros prefijos a todos los ISP genera problemas y se hace necesario dirigir nuestras redes a un solo ISP. Sin embargo, ante eventualidades como la falla del ISP principal, se requiere la capacidad de redirigir nuestros anuncios hacia el ISP de respaldo.

Por ejemplo, si no recibimos la red 8.8.8.8/32 desde ISP1, deseamos anunciar nuestras redes a ISP2.
Antes de proceder con la configuración, es crucial comprender dos comandos clave: 'non-exist-map' y 'advertise-map'.
  • advertise-map: Un route-map que contiene los prefijos que deseamos anunciar a nuestros ISP.
  • non-exist-map: Un route-map que define el prefijo cuya ausencia en la tabla BGP genera la condición para anunciar los prefijos asociados al route-map de 'advertise-map'.
  • exist-map: Un route-map que define el prefijo cuya presencia en la tabla BGP genera la condición para anunciar los prefijos asociados al route-map correspondiente al "advertise-map".
Escenario: 
Imaginemos que nuestra empresa cuenta con dos ISP. Debido a restricciones en las políticas de enrutamiento, un ISP externo no nos permite influir en el tráfico mediante la técnica de Prepend (NTT, con una local preference de 120 para su peer Telmex). Por lo tanto, es esencial anunciar únicamente nuestros prefijos al ISP Level3 y, en caso de que este deje de publicar algunos prefijos o experimente una falla, anunciar nuestros prefijos al ISP TELMEX (ASN 6429).



A continuación vamos a comenzar mostrando la configuración base de R1.
R1#show running-config
!
interface Ethernet0/0
 description TO_TELMEX
 ip address 1.1.1.2 255.255.255.252
!
interface Ethernet0/1
 description TO_LEVEL_3
 ip address 9.9.9.2 255.255.255.252
!
interface Ethernet0/2
 ip address 172.16.1.1 255.255.255.0
!
router bgp 2323
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 network 172.16.2.0 mask 255.255.255.0
 neighbor 1.1.1.1 remote-as 6429
 neighbor 1.1.1.1 description ISP_TELMEX
 neighbor 1.1.1.1 fall-over bfd
 neighbor 1.1.1.1 route-map REDES_ANUNCIADAS out
 neighbor 1.1.1.1 filter-list 15 out
 neighbor 9.9.9.1 remote-as 3349
 neighbor 9.9.9.1 description ISP_LEVEL3
 neighbor 9.9.9.1 fall-over bfd
 neighbor 9.9.9.1 route-map REDES_ANUNCIADAS out
 neighbor 9.9.9.1 filter-list 15 out
!
ip forward-protocol nd
!
ip as-path access-list 15 permit ^$
ip as-path access-list 15 deny .*
!
ip route 172.16.2.0 255.255.255.0 Null0
!
ip prefix-list REDES_PUBLICAS_EMPRESA seq 5 permit 172.16.1.0/24
ip prefix-list REDES_PUBLICAS_EMPRESA seq 10 permit 172.16.2.0/24
!
route-map REDES_ANUNCIADAS permit 10
 match ip address prefix-list REDES_PUBLICAS_EMPRESA
!
Se visualiza una configuración estándar de R1, en la cual anuncia sus redes a ambos ISP. A continuación, se presenta una verificación de esto.

Ahora que estamos al tanto del estado actual de nuestra configuración, procederemos a establecer la condición para la publicación de redes. La condición que deseamos crear es la siguiente:
  • Si dejo de recibir el prefijo 8.8.8.8/32 desde mi peer de Level 3 (ASN 3349), procedo a anunciar o publicar mis prefijos a mi peer de Telmex (ASN 6429).
Teniendo claro lo que deseamos lograr, comenzaremos revisando nuestra tabla BGP para asegurarnos de que estos prefijos estén presentes en ella.
Observamos que el prefijo 8.8.8.8/32 está siendo anunciado a R1 por ambos peers. Ahora procederemos a crear los route-map que definirán la condición para la advertencia o anuncio de prefijos.

  • Creamos una lista de prefijos (prefix-list) o una lista de control de acceso (ACL) que marque el prefijo que utilizaremos como condición: 8.8.8.8/32.

  • Dado que sabemos que el anuncio de este prefijo pasa a través del ASN 3349, creamos un as-path que refleje esta información.

ip prefix-list TRACK_PREFIX seq 5 permit  8.8.8.8/32
!
ip as-path access-list 11 permit _3349_
  • Se crea un route-map que asocie la lista de prefijos (prefix-list) con el AS-path. Específicamente, estamos hablando del "prefijo 8.8.8.8/32 que pase por el ASN 3349".
route-map EXIST permit 10
 match ip address prefix-list TRACK_PREFIX
 match as-path 11
  • Procedemos a aplicar el route-map "EXIST" a nuestro par de TELMEX (ASN 6429) de manera condicional.
router bgp 2323
! Quitamos nuestro route-map anterior que anunciaba nuestras redes.
 no neighbor 1.1.1.1 route-map REDES_ANUNCIADAS out
! Aplicamos nuestra condición: "si no existe el prefijo 8.8.8.8/32 que pase a través del ASN 3349 en la BGP table, le publicamos las redes a nuestro par de Telmex (ASN 6429)".
 neighbor 1.1.1.1 advertise-map REDES_ANUNCIADAS non-exist-map EXIST

A continuación, verificamos el anuncio de las redes a nuestros peers.
Como se puede observar, las redes ya no se anuncian a nuestro peer de Telmex, pero sí a nuestro peer de Level 3. A continuación, verificamos que en la tabla BGP esté presente el prefijo que condiciona el anuncio de prefijos a dicho peer
Ahora procederemos a simular una falla en nuestro enlace de Level 3. Nuestro par ha experimentado un corte de fibra, lo que ha llevado a la interfaz e0/1 a un estado "down".
A continuación, verificamos el estado de nuestros pares BGP y observamos que 9.9.9.1 (Level 3) se encuentra en estado "Idle".
Revisamos que nuestros prefijos se estén anunciando a nuestro peer de Telmex (ASN 6429).
Observamos que la situación prevista se está materializando, ya que estamos advirtiendo nuestros prefijos al par de Telmex (ASN 6429) debido a la ausencia de 8.8.8.8/32 en nuestra tabla BGP, y este prefijo pasa a través del ASN 3349.
A continuación, se restaura la normalidad en nuestro enlace de Level 3, y observamos que la advertencia de prefijos solo se realiza a través de nuestro par de Level 3, como se esperaba.
Otra forma de verificar que la condición de anuncio de prefijos esté aplicada es mediante el siguiente comando:
R1#show ip bgp neighbors 1.1.1.1
BGP neighbor is 1.1.1.1,  remote AS 6429, external link
 Description: ISP_TELMEX
 Fall over configured for session
 BFD is configured.
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:41:56
 !--- Output suppressed.
For address family: IPv4 Unicast
  Session: 1.1.1.1
  BGP table version 11, neighbor version 11/0
  Output queue size : 0
  Index 5, Advertise bit 0
  5 update-group member
  Outbound path policy configured
  Outgoing update AS path filter list is 15
  Condition-map EXIST, Advertise-map REDES_ANUNCIADAS, status: Withdraw
  Slow-peer detection is disabled
!--- Output suppressed.

En el cual se muestra que el anuncio está en estado "Withdraw" que significa retirado en español, es decir, no estamos anunciando rutas a ese par. A continuación, dejo el resumen de la configuración de R1.

 Configuración final de R1.
interface Ethernet0/0
 description TO_TELMEX
 ip address 1.1.1.2 255.255.255.252
!
interface Ethernet0/1
 description TO_LEVEL_3
 ip address 9.9.9.2 255.255.255.252
!
interface Ethernet0/2
 ip address 172.16.1.1 255.255.255.0
!
router bgp 2323
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 network 172.16.2.0 mask 255.255.255.0
 timers bgp 5 15
 neighbor 1.1.1.1 remote-as 6429
 neighbor 1.1.1.1 description ISP_TELMEX
 neighbor 1.1.1.1 fall-over bfd
 neighbor 1.1.1.1 advertise-map REDES_ANUNCIADAS non-exist-map EXIST
 neighbor 1.1.1.1 filter-list 15 out
 neighbor 9.9.9.1 remote-as 3349
 neighbor 9.9.9.1 description ISP_LEVEL3
 neighbor 9.9.9.1 fall-over bfd
 neighbor 9.9.9.1 route-map REDES_ANUNCIADAS out
 neighbor 9.9.9.1 filter-list 15 out
!
ip as-path access-list 11 permit _3349_
ip as-path access-list 15 permit ^$
ip as-path access-list 15 deny .*
!
ip route 172.16.2.0 255.255.255.0 Null0
!
ip prefix-list REDES_PUBLICAS_EMPRESA seq 5 permit 172.16.1.0/24
ip prefix-list REDES_PUBLICAS_EMPRESA seq 10 permit 172.16.2.0/24
!
ip prefix-list TRACK_PREFIX seq 5 permit 8.8.8.8/32
!
route-map REDES_ANUNCIADAS permit 10
 match ip address prefix-list REDES_PUBLICAS_EMPRESA
!
route-map EXIST permit 10
 match ip address prefix-list TRACK_PREFIX
 match as-path 11

Fin del post. Si hay algún error, por favor, házmelo saber.

Comentarios

Publicar un comentario

Entradas más populares de este blog

Uso de banners en Cisco IOS

-
El siguiente documento ha sido elaborado para clarificar la forma correcta de configurar banners en routers y switches Cisco. La información proporcionada se basa en los libros de ICND1 e ICDN2 de Cisco Press. Los banners disponibles para Cisco IOS son los siguientes: Banner motd. Banner exec. Banner Login. A continuación, definimos su uso: Banner MOTD (Message of the Day): Se muestra después del login y se utiliza para mensajes temporales que cambian periódicamente, por ejemplo, "SW1 estará en mantenimiento esta noche entre las 21 y las 23 horas". Banner Exec: Se muestra después del login y se utiliza para proporcionar información que solo debe conocerse por los usuarios autorizados. Por ejemplo, "El personal del NOC no estará presente hoy, por favor, evite realizar configuraciones de alto impacto". Banner Login: Se muestra antes del login y también después del banner MOTD. Se utiliza para mensajes permanentes como "acceso solo a personal autorizado".
Leer más