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:
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.
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 |