Implementación de políticas de peering mediante communities en DE-CIX Madrid

Implementación de políticas de peering mediante communities en DE-CIX Madrid

A continuación presentamos ejemplos de implementación de políticas mediante BGP communities en la conexión a los route-servers de DE-CIX Madrid. La utilidad de la aplicación de estas políticas sirve, por ejemplo, para no hacer peering en DE-CIX Madrid con un AS con el que ya estamos intercambiando prefijos en NIXVAL-ix, que en determinados escenarios puede no ser necesario.

Las políticas soportadas son las siguientes:

Política Community
Bloquear el anuncio de una ruta a un peer específico : 0:[peer-as]
Anunciar una ruta a un peer : 48793:[peer-as]
Bloquear el anuncio de una ruta a todos los peers: 0:48793
Anunciar una ruta a todos los peers: 48793:48793

Cualquier community que no empiece por 0: o 48739: se ignora, y los anuncios que no llevan communities se propagan siempre a todos los peers.

A continuación un ejemplo simplificado para la configuración de routers CISCO para conectarse a los route-servers de DECIX Madrid e implementar un filtro de salida que anuncia las communities requeridas para que el contenido de un filtro NO se anuncie al AS 1234:


router bgp 57542
no bgp enforce-first-as #(IMPRESCINDIBLE!!)
neighbor decixrs peer-group
neighbor decixrs remote-as 48793
neighbor decixrs route-map decixrs_out out
neighbor decixrs maximum-prefix 200
neighbor 185.1.68.252 peer-group decixrs
neighbor 185.1.68.253 peer-group decixrs
....

route-map decixrs_out
match as-path 10 #(filtro de salida que se utilice, prefix-list, etc...)
set community 0:1234 48793:48793

Esta última línea es la que especifica a los route servers que los prefijos que se identifican mediante el as-path 10 no se anuncien al AS 1234, y sí a todos los demás peers presentes en los route-servers.