11. Configuración de BGP

Transcripción

1 11. Configuración de BGP En este apartado se van a ver los pasos necesarios para la configuración de BGP y una serie de ejemplos prácticos de configuración de routers BGP. Además, se van a tratar otros aspectos importantes en la configuración como la sincronización, el uso de comunidades para filtrado mediante listas de acceso, el uso de peer groups para la aplicación de políticas de encaminamiento mediante route maps y la agregación de rutas Habilitando el encaminamiento BGP En primer lugar, se va a suponer que se dispone de dos routers BGP llamados RTA y RTB, los cuales no tienen por qué ser adyacentes, y entre los que se va a establecer una sesión BGP para el intercambio de información de encaminamiento. En el primer ejemplo, RTA y RTB pertenecen a diferentes AS, mientras que en el segundo ambos se encuentran en el mismo AS. La primera acción a realizar en la configuración de un router BGP es definir el proceso BGP y el número de AS al que el router pertenece. El comando utilizado para habilitar BGP en un router es: router bgp ASN. En el primer ejemplo se van a configurar los routers RTA y RTB para que ejecuten el proceso BGP y para indicar que pertenecen a los AS100 y AS200, respectivamente. Las sentencias necesarias para ello serían las siguientes: RTA# router bgp 100 RTB# router bgp 200 Ejemplo 1:

2 El siguiente paso en el proceso de configuración consiste en definir los vecinos BGP, es decir, los routers con los que se intentará establecer una sesión BGP (peering). Dos routers se convierten en vecinos (peers) cuando se establece una conexión TCP entre ambos para el intercambio de actualizaciones de rutas. Una vez establecida la conexión TCP, ambos routers se envían mensajes OPEN para intercambiar parámetros como sus ASN, la versión BGP que utilizan, el router ID y el tiempo de espera para el envío de mensajes KEEPALIVE (enviados para asegurar que la conexión permanezca activa). Después de que estos valores sean confirmados y aceptados la sesión BGP podrá establecerse entre los vecinos. El comando utilizado para establecer la conexión TCP con un vecino es el siguiente: neighbor dir_ip remote-as ASN. El número de AS corresponde al AS remoto al que pertenece el router con el que se quiere conectar y cuya dirección IP es dir_ip. En el caso de sesiones E-BGP la dirección IP corresponde a la interfaz del router directamente conectado (next hop), mientras que en el caso de una sesión I-BGP la dirección IP indicada puede ser una cualquiera de las del router destino, el cual no tiene por qué estar directamente conectado al router origen. Un aspecto que es necesario tener en cuenta es que las dos direcciones IP configuradas con el comando neighbor en cada router sean alcanzables entre sí. Para verificarlo, una forma segura es mediante el uso del comando ping forzando al router a que utilice como dirección IP fuente la especificada en el comando neighbor en lugar de la dirección IP de la interfaz por la que realmente se envía el ping. Otro aspecto importante es aplicar un reset a la conexión con el vecino de tal forma que los cambios realizados en la configuración tengan efecto. Para ello, se puede utilizar el comando clear ip bgp dir_ip (donde dir_ip es la dirección IP del vecino) o clear ip bgp * (para resetear todas las conexiones con los vecinos). En el ejemplo 1 la configuración de los vecinos BGP sería la siguiente: RTA# router bgp 100 neighbor remote-as 200 RTB# router bgp 200 neighbor remote-as 100 neighbor remote-as 200 RTC# router bgp 200 neighbor remote-as 200

3 En este caso los routers RTA y RTB hacen uso de E-BGP, mientras que el router RTC usa I-BGP, lo cual puede comprobarse al coincidir el ASN del AS del router RTC y el ASN del vecino indicado (ASN=200). Además, los vecinos E-BGP deben estar directamente conectados, por lo que los routers RTA y RTB tienen direcciones IP que pertenecen al mismo segmento de red ( /24). Por otro lado, para la configuración de las sesiones I-BGP se utilizan normalmente interfaces loopback, las cuales permiten asegurar las sesiones I-BGP indicando una dirección IP virtual para un vecino mediante el comando neighbor, de manera que dicha dirección IP sea independiente a las interfaces físicas del router vecino y se pueda establecer la sesión I-BGP por una o por otra interfaz física. Del lado del vecino, éste debe indicar al proceso BGP que está utilizando una interfaz loopback en lugar de una interfaz física para el inicio de la conexión TCP con el vecino. El comando utilizado para indicar una interfaz loopback de un vecino es el siguiente: neighbor dir_ip update-source interfaz. El siguiente ejemplo muestra el uso de este comando: Ejemplo 2: RTA# router bgp 100 neighbor remote-as 100 neighbor update-source int loopback 1 RTB# router bgp 100 neighbor remote-as 100 En el ejemplo anterior, RTA y RTB están ejecutando I-BGP en el interior del AS 100. El router RTB utiliza la interfaz loopback de RTA ( ) mediante el comando neighbor. En este caso, el router RTA debe forzar que BGP use la dirección IP loopback definida como dirección fuente en la conexión TCP con el vecino. Para ello, con la sentencia neighbor update-source int loopback 1, el router RTA fuerza a BGP a que use la dirección IP de su interfaz loopback cuando se comunica con el vecino En cambio, RTA indica mediante el comando neighbor la dirección IP que se corresponde con la dirección de la interfaz física del router RTB, por lo que RTB no tiene que hacer ninguna configuración especial.

4 11.2. Comandos para el envío de rutas Una vez visto cómo se inicia el proceso BGP y cómo se definen los vecinos, en este apartado se van a ver dos formas de configuración para el envío de información de encaminamiento mediante BGP. En realidad, un router BGP envía a un vecino las rutas que aprende de otros vecinos (internos o externos), pero también puede generar nuevas rutas mediante los comandos network y redistribute. De este modo, para las rutas generadas de esta manera el AS origen corresponderá al AS al que pertenece el router que ejecuta los dos comandos anteriores. El formato del comando network es el siguiente: network network-number [mask network-mask]. Este comando indica al proceso BGP las rutas que debe anunciar, las cuales se expresan como una dirección IP y una máscara. Para que estas rutas puedan ser anunciadas es necesario que el router las conozca, bien a través de encaminamiento estático o dinámico, o bien porque las redes destino estén conectadas directamente al router. El número máximo de redes a anunciar mediante este comando es de 200. La siguiente configuración muestra un ejemplo de uso de este comando: RTA# router bgp 100 network mask ip route null 0 En este ejemplo el router RTA generará una entrada en la lista de redes a anunciar para el prefijo /16. La máscara indica que se van a anunciar los dos primeros octetos de la ruta Dicha ruta necesita ser añadida a la tabla de encaminamiento del router, para lo cual se utiliza el comando estático ip route. Otra forma de anunciar rutas en BGP es redistribuyendo las rutas aprendidas por el router mediante un protocolo IGP. Es importante en este caso aplicar políticas de filtrado de manera que no se distribuyan al exterior de un AS todas las rutas aprendidas internamente por el protocolo IGP, sino sólo aquéllas que se quieren anunciar. En el siguiente ejemplo, el router RTA anuncia la ruta y RTC anuncia la ruta :

5 RTC# router rip network redistribute bgp 200 router bgp 200 neighbor remote-as 300 neighbor distribute-list 1 out redistribute rip access-list 1 permit La lista de acceso se utiliza para controlar las rutas que van a ser anunciadas desde el AS 200. Así, sólo se anunciará el prefijo , evitando que se anuncie la ruta como si su AS origen fuese el AS 200 en vez del AS 100. Al igual que se pueden redistribuir las rutas aprendidas a través de un protocolo IGP, en BGP también es posible redistribuir las rutas configuradas estáticamente en la tabla de encaminamiento, para lo cual se utiliza el comando redistribute static. La única diferencia en este caso es que BGP considera estas rutas con un origen INCOMPLETE (no conocido). Un aspecto importante a destacar es que un router no acepta anuncios de una sesión BGP si las rutas tienen origen en el AS al que dicho router pertenece. Esto se hace para evitar bucles inter-as Internal BGP I-BGP se utiliza en un AS en el caso de que dicho AS funcione como sistema de tránsito para otros AS. Este protocolo se utiliza de forma específica para el intercambio de rutas entre routers de borde BGP de un mismo AS, de manera que se consigue una mayor eficiencia y flexibilidad que en el caso de E-BGP con redistribución de rutas mediante un protocolo IGP. Por ejemplo, el uso de I-BGP permite elegir el router de salida del AS, para lo cual se modifica el atributo LOCAL_PREF. En la figura que se muestra a continuación se puede ver un ejemplo de sesiones I-BGP dentro de un AS:

6 RTA# router bgp 100 neighbor remote-as 100 neighbor remote-as 300 network RTB# router bgp 100 neighbor remote-as 100 neighbor remote-as 400 network RTC# router bgp 400 neighbor remote-as 100 network En la configuración anterior se tienen dos sesiones I-BGP establecidas: una entre RTA y RTB, y otra entre RTA y RTD. Los anuncios BGP provenientes de RTB hacia RTA serán reenviados por RTA hacia RTE (que pertenece a otro AS), pero no hacia RTD (perteneciente al mismo AS). Ésta es la causa por la que en este diagrama debería existir también una sesión entre RTB y RTD, de forma que se establezca una malla completa (full mesh) entre todos los routers I-BGP del AS 100. Como conclusión, se puede afirmar que cuando un router BGP recibe un anuncio de otro router BGP de su propio AS (I-BGP peers), el router receptor no redistribuirá dicho anuncio a otro router de su mismo AS. Por el contrario, dicho anuncio sí será redistribuido al resto de routers vecinos que pertenecen a otros AS.

7 11.4. Sincronización Como introducción al concepto de sincronización se plantea el siguiente escenario de ejemplo: En este escenario el router RTC (AS 300) envía anuncios de la red Los routers RTA y RTB se intercambian información de encaminamiento por I-BGP (no es necesario que estén directamente conectados), por lo que RTB recibirá la ruta con NEXT_HOP igual a (el valor de este atributo no se modifica por I-BGP). Para alcanzar el NEXT_HOP RTB tendrá que enviar el tráfico al router intermedio RTE. El problema surge si RTA no ha redistribuido la red al resto de routers del AS mediante IGP, de forma que en dicho caso RTE no sabría cómo encaminar el tráfico proveniente de RTB hacia el AS 300. Además, RTB anunciará dicha ruta a otros vecinos (RTD, por ejemplo) y todo el tráfico que se envíe a dicha ruta no llegará a su destino debido a que RTE no la conoce. El mecanismo de sincronización funciona por defecto en todos los routers BGP y se aplica para evitar el problema anterior en el caso de que un AS sirva de tránsito para el tráfico proveniente de otro AS hacia un AS tercero. Así, para conseguir la sincronización un router no puede anunciar una ruta a otra AS antes de que todos los routers del AS al que pertenece el router anunciante hayan aprendido dicha ruta mediante IGP. Por esto, los pares de routers de borde de dos AS distintas (peers externos) tendrán que esperar cuando quieran anunciar una ruta de otro AS a que dicha ruta se haya propagado por IGP en todo los routers su mismo AS. En el ejemplo anterior, el router RTB tendrá que esperar a recibir la ruta (que ya conoce por I-BGP) por IGP antes de comenzar a enviar anuncios al router RTD del AS 400.

8 En algunos casos no es necesario el mecanismo de sincronización, como por ejemplo cuando un AS no sirve de tránsito para el tráfico intercambiado entre dos AS o cuando en todos los routers del AS funciona BGP. La finalidad de deshabilitar el mecanismo de sincronización en los casos en que no es necesario es evitar el envío de menos rutas por IGP y conseguir una convergencia más rápida de BGP. En el caso de que se tenga un AS con todos los routers BGP y no se tenga ningún protocolo IGP funcionando, la desactivación del mecanismo de sincronización se hace necesaria ya que un router se quedaría esperando indefinidamente a recibir una ruta por IGP antes de anunciarla a un router externo (external peer). Para desactivar la sincronización de forma manual se utiliza el comando no synchronization. El siguiente ejemplo muestra un caso en el que se desactiva la sincronización: RTB# router bgp 100 network neighbor remote-as 400 neighbor remote-as 100 no synchronization (RTB guardará la ruta en su tabla de encaminamiento y la anunciará al router RTD incluso si no dispone de un camino IGP para llegar). RTD# router bgp 400 neighbor remote-as 100 network RTA# router bgp 100 network neighbor remote-as 100

9 11.5. Fitrado mediante listas de acceso El envío y recepción de actualizaciones BGP se puede controlar mediante el uso de diferentes métodos de filtrado. El filtrado de anuncios se aplica en una sesión BGP para permitir o denegar los mensajes UPDATE enviados o recibidos, basándose en informaciones como la dirección de la ruta anunciada, la trayectoria de AS seguida o la comunidad a la que pertenece el destino anunciado Route Filtering Para restringir la información de encaminamiento que un router aprende o anuncia basándose en la dirección de las rutas intercambiadas se utilizan las listas de acceso. Una lista de acceso se aplica a la sesión entre un router y uno de sus vecinos, para lo cual se utiliza el comando neighbor {ip-address peer-group-name} distribute-list access-list-number {in out}. En el siguiente ejemplo, el router RTB origina la red y la anuncia a RTC. En este caso, el router RTC no debe propagar dicha ruta hacia el AS100 para no servir de tránsito para llegar a dicho destino. Por ello, será necesario aplicar una lista de acceso a la sesión entre RTC y RTA que filtre la ruta para que RTC no la anuncie a RTA. RTC# router bgp 300 network neighbor remote-as 200 neighbor remote-as 100 neighbor distribute-list 1 out access-list 1 deny access-list 1 permit

10 Path Filtering Otro tipo de listas de acceso se basa en el atributo AS_PATH de los mensajes BGP anunciados o recibidos. La sintaxis para definir una lista de acceso de este tipo y para aplicarla a una sesión BGP es la siguiente: ip as-path access-list access-list-number {permit deny} as-regularexpression neighbor {ip-address peer-group-name} filter-list access-list-number {in out} En la figura anterior, para bloquear el anuncio de la ruta desde el router RTC hacia el AS 100 también se puede aplicar una lista de acceso basada en el AS_PATH. Para ello, se pueden descartar los anuncios de RTC a RTA cuyo origen sea el AS 200. La configuración necesaria para aplicar una lista de acceso a los anuncios de salida de RTC que elimine los anuncios con origen en el AS 200 es la siguiente: RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor filter-list 1 out ip as-path access-list 1 deny ^200$ ip as-path access-list 1 permit.* En la configuración anterior, la lista de acceso definida (lista 1) deniega los anuncios cuyo AS_PATH comienza por 200 (^) y termina por 200 ($). La expresión.* indica que la lista se aplica a cualquier AS_PATH, lo cual es necesario para permitir el anuncio del resto de actualizaciones. En el caso de que se hubiese utilizado la expresión ^200 en vez de ^200$, se negarían todos los anuncios cuyo AS_PATH comience por 200. Así, una ruta originada en un AS vecino del AS 200 (AS 400, por ejemplo) tendrá un AS_PATH de la forma (200, 400) al llegar al router RTC, por lo que no sería anunciada al AS Community Filtering Otro método de filtrado se basa en el atributo COMMUNITY. En el ejemplo siguiente, el router RTB añade el atributo COMMUNITY con el valor no-export a las rutas que anuncia a RTC para que estas rutas no sean propagadas por RTC hacia el AS 100.

11 La configuración del router RTB debe ser la siguiente: RTB# router bgp 200 network neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out route-map setcommunity match ip address 1 set community no-export access-list 1 permit En esta configuración se puede ver cómo se utiliza el route map setcommunity para modificar el atributo COMMUNITY al valor no-export. Para que este atributo sea enviado al vecino RTC, es necesario el comando neighbor send-community indicando la dirección IP de RTC. Cuando RTC recibe un anuncio con el atributo COMMUNITY con el valor no-export, éste no lo propagará a su vecino RTA. Aparte del filtrado, otro uso de listas de acceso basadas en el atributo COMMUNITY consiste en modificar otros atributos (como WEIGHT o METRIC) de las rutas a anunciar. Para definir una lista de acceso basada en comunidades se utiliza el comando ip community-list community-list-number {permit deny} community-number. En el siguiente ejemplo, el router RTB añade los valores 100 y 200 a la lista de comunidades del atributo COMMUNITY que contienen las rutas antes de que éstas sean anunciadas. Además, se indica que se quiere enviar el atributo COMMUNITY en los anuncios enviados al vecino RTC mediante la opción send-community del comando neighbor. RTB# router bgp 200

12 network neighbor remote-as 300 neighbor send-community neighbor route-map setcommunity out route-map setcommunity match ip address 2 set community additive access-list 2 permit Por otra parte, el router RTC recibirá las rutas de RTB y aplicará un route map (check-community) para modificar los atributos de las rutas recibidas (atributo WEIGHT, por ejemplo) basándose en el atributo COMMUNITY. RTC# router bgp 300 neighbor remote-as 200 neighbor route-map check-community in route-map check-community permit 10 match community 1 set weight 20 route-map check-community permit 20 match community 2 exact set weight 10 route-map check-community permit 30 match community 3 ip community-list 1 permit 100 ip community-list 2 permit 200 ip community-list 3 permit Internet En el ejemplo de configuración anterior, el router RTC modifica las rutas recibidas de la siguiente manera: Cualquier ruta que tenga el valor 100 en su atributo COMMUNITY coincidirá con la lista 1 y se modificará el valor de su atributo WEIGHT a 20. Cualquier ruta cuyo atributo COMMUNITY contenga sólo el valor 200 será modificada con un valor de WEIGHT igual a 10 (la opción exact indica que el valor de COMMUNITY sólo puede ser de 200 y ningún otro). La última lista sirve para asegurar que el resto de actualizaciones recibidas no se descartan (por defecto se descartan todas las rutas que no coinciden con ninguna condición). La opción Internet se refiere a todas las rutas, ya que todas las rutas forman parte de la comunidad Internet Route Maps En este apartado se va a introducir el uso de los route maps ya que se van a utilizar en configuraciones posteriores. En el contexto de BGP, un route map consiste en un método para controlar y modificar la información de encaminamiento. Esto se hace definiendo condiciones que se aplican a las rutas redistribuidas de un protocolo de encaminamiento a otro, así como a las rutas recibidas y a las anunciadas. El formato que sigue un route map es el siguiente: route-map map-tag [[permit deny] [sequence-number]]. El valor de map-tag se corresponde con el nombre

13 del route map, de manera que se pueden definir múltiples instancias del mismo route map mediante su nombre. Del mismo modo, el valor sequence-number sirve para indicar la posición de un nuevo route map en una lista de route maps configurados con el mismo nombre. Por ejemplo, si se definen dos instancias de un route map llamado MYMAP, la primera instancia podría tener un número de secuencia igual a 10 y la segunda instancia un valor de 20: route-map MYMAP permit 10 (primer conjunto de condiciones) route-map MYMAP permit 20 (segundo conjunto de condiciones) Cuando se aplica el route map MYMAP a las rutas de entrada o de salida, el primer conjunto de condiciones que se evalúan corresponde a la instancia con número de secuencia 10. Así, si no se cumplen dichas condiciones para la ruta de entrada o salida, se evalúan entonces las condiciones de una instancia con número de secuencia mayor, y así sucesivamente. Cada instancia de un route map consiste en una lista de comandos match y set, cuyas funciones son, respectivamente, aplicar condiciones a las rutas y modificar sus atributos. Por ejemplo, los siguientes comandos consisten en modificar la métrica de las rutas que anuncien la dirección IP : match ip address set metric 5 Una vez evaluadas las condiciones (comando match) de la primera instancia del route map, la ruta será redistribuida o se le aplicará la acción especificada (comando set) sólo en el caso de que se haya indicada la opción permit en el route map en cuestión, y se terminará de analizar el route map. En cambio, si la opción indicada fue deny, la ruta no será redistribuida o controlada y se finalizará el análisis del route map sin comprobar el resto de instancias. Por otra parte, en el caso de que no se cumpla ninguna condición para la ruta, se pasa a la siguiente instancia del route map (el siguiente número de secuencia) así hasta que se cumpla algún match o no queden instancias en el route map. En este último caso, si no se cumple ningún match la ruta no será aceptada ni reenviada. Las diferentes opciones que permite el comando match son las siguientes: match as-path, match community, match clns, match interface, match ip address, match ip next-hop, match ip route-source, match metric, match route-type, match tag. Las opciones relacionadas con el comando set son las siguientes: set as-path, set clns, set automatic-tag, set community, set interface, set default interface, set ip default next-hop, set level, set local-preference, set metric, set metric-type, set next-hop, set origin, set tag, set weight. En el siguiente ejemplo se van a ver dos casos de uso de route maps para el filtrado y para el control de las rutas anunciadas entre dos sistemas autónomos:

14 En primer lugar se va a suponer que los routers RTA y RTC intercambian rutas mediante BGP, mientras que RTA y RTB utilizan RIP para intercambiar las rutas en el interior del AS 100. De este modo, RTA obtendrá rutas externas a través de una sesión E-BGP con RTC, las cuales redistribuirá a RTB mediante RIP. La siguiente configuración aplica un control a las rutas redistribuidas a RTC, cambiando las métricas para que valgan 2 en el caso de las rutas pertenecientes al prefijo /16, y 5 para el resto de rutas. RTA# router rip network network network passive-interface Serial0 redistribute bgp 100 route-map SETMETRIC router bgp 100 neighbor remote-as 300 network route-map SETMETRIC permit 10 match ip-address 1 set metric 2 route-map SETMETRIC permit 20 set metric 5 access-list 1 permit En la configuración anterior, si una ruta pertenece al prefijo indicado se cambiará su métrica a un valor de 2 y en ese caso se terminará de analizar el route map. En caso contrario, se aplica la segunda instancia que cambia por defecto el valor de la métrica de todas las rutas a 5. En esta configuración del route map se aplica una accesslist con el número 1 para indicar la condición del prefijo, utilizando para ello una máscara invertida.

15 Otro caso de uso de un route map, además de la modificación de los atributos de las rutas, puede ser el filtrado de rutas, de modo que se acepten o reenvíen sólo las rutas que cumplan unas condiciones. Como ejemplo, en la figura anterior se podría haber configurado el router RTA para que el AS 100 no acepte anuncios de rutas pertenecientes al prefijo Sin embargo, un route map no se puede aplicar a las rutas de entrada cuando se aplican condiciones basadas en la dirección IP. Por esto, lo que se puede hacer es configurar RTC para que no anuncie dichas rutas a su salida: RTC# router bgp 300 network neighbor remote-as 100 neighbor route-map STOPUPDATES out route-map STOPUPDATES permit 10 match ip address 1 access-list 1 deny access-list 1 permit Filtrado y modificación de atributos mediante Route maps El comando neighbor se puede utilizar junto con los route maps para realizar acciones de filtrado y modificación de atributos de las actualizaciones tanto de entrada como de salida intercambiadas con un vecino BGP. Los route maps aplicados a los anuncios de entrada no tienen efecto cuando las condiciones (match) indicadas se basan en la dirección IP. El comando utilizado para asociar un route map a una sesión con un vecino BGP es el siguiente: neighbor ip-address route-map route-map-name. En el siguiente ejemplo se configura un route map en el router RTC para que sólo acepte los anuncios de redes que son locales al AS200. Además, se quiere modificar el atributo WEIGHT de dichos anuncios recibidos a un valor de 20. Para conseguir dicha configuración se puede utilizar un route map junto con listas de acceso basadas en el atributo AS_PATH.

16 RTC# router bgp 300 network neighbor remote-as 200 neighbor route-map stamp in route-map stamp match as-path 1 set weight 20 ip as-path access-list 1 permit ^200$ En la configuración anterior, todas las actualizaciones recibidas cuyo AS_PATH comienza por el ASN 200 y termina también por el ASN 200 son aceptadas, mientras que el resto de anuncios son descartados. Otra configuración posible para el router RTC en el mismo escenario podría llevar a cabo las siguientes acciones sobre los anuncios recibidos: Los anuncios con origen en el AS 200 se aceptan y se modifica su atributo WEIGHT al valor 20. Los anuncios originados en el AS 400 son directamente descartados. El resto de anuncios son modificados con un WEIGHT igual a 10. RTC# router bgp 300 network neighbor remote-as 200 neighbor route-map stamp in route-map stamp permit 10 match as-path 1 set weight 20 route-map stamp permit 20 match as-path 2 set weight 10

17 ip as-path access-list 1 permit ^200$ ip as-path access-list 2 permit ^ * En algunas situaciones es necesario modificar el atributo AS_PATH para control ar e l proceso de decisión BGP. Esto se puede hacer mediante el uso del siguiente comando en un route map: set as-path prepend<as-path#<as-path#... Un ejemplo de decisión de una ruta en función del atributo AS_PATH puede verse en el escenario anterior. Supóngase en este caso que el router RTC anuncia una ruta propia ( ) por dos AS diferentes: el AS 100 y el AS 200. Cuando estos anuncios se propagan y llegan al AS 600, los routers del AS 600 tendrán información sobre la red por dos caminos distintos: uno a través del AS 100 con AS_PATH (100, 300) y otro a través del AS 400 con AS_PATH (400, 200, 300). En el caso anterior, si se asume que todos los atributos son iguales excepto el AS_PATH, los routers del AS 600 elegirán el camino más corto a través del AS 100, por lo que el AS 300 recibirá todo su tráfico por el AS 100. Si se quiere cambiar el proceso de decisión en el AS 600, se podría modificar el AS_PATH de los anuncios que provienen el AS 100 para que sea más largo que el de los anuncios que provienen del AS 400. Esto puede realizarse añadiendo varios números de AS al AS_PATH de los anuncios que vienen del AS 100. Una práctica sencilla consiste en repetir el ASN propio en los anuncios para hacer que éstos sean peores rutas hacia el AS 300, como puede verse en la siguiente configuración: RTC# router bgp 300 network neighbor remote-as 100 neighbor route-map SETPATH out route-map SETPATH set as-path prepend El router RTC anuncia a RTA la ruta con un AS_PATH más largo (se repite el ASN 300). Así, los routers del AS 600 recibirán los anuncios de la ruta a través del AS 100 con un AS_PATH igual a (100, 300, 300, 300), el cual es más largo que el recibido mediante el AS 100 (400, 200, 300) BGP Peer Groups Otra forma de aplicar políticas de encaminamiento mediante route maps es utilizando peer groups, los cuales también pueden ser utilizados en las distribute-lists y las filter-lists. Un peer group es un grupo de vecinos BGP a los que se le aplica la misma política de encaminamiento, de manera que definiendo un peer group no es necesario definir la misma política para cada vecino por separado, sino que se define un peer group al que se le asignan las políticas comunes. Los miembros de un peer-group heredan todas las opciones de configuración de dicho peer-group. Además, cada miembro del grupo puede sobrescribir dicha configuración, aunque esto sólo es posible para las condiciones que se aplican a la política de los anuncios de entrada. Para definir un peer-group se utiliza el comando siguiente: neighbor peer-group-name peer-group. En el siguiente ejemplo se

18 utilizan dos peer groups, cada uno de los cuales se utiliza para aplicar la misma política a los vecinos internos (internalmap), por un lado, y a los vecinos externos (externalmap) por otro. En la siguiente configuración se define un peer group en el router RTC llamado internalmap, el cual se aplica a todos sus vecinos internos (RTE, RTF y RTG). Este peer group define un route map (SETMETRIC), el cual modifica la métrica a 5, y dos filter lists (listas 1 y 2). Además, se define la filter-list 3 que se aplica al vecino RTE, sobrescribiendo la filter-list 2 del peer group sólo para la sesión con este vecino (sólo se pueden sobrescribir opciones que afecten a los anuncios de entrada). RTC# router bgp 300 neighbor internalmap peer-group neighbor internalmap remote-as 300 neighbor internalmap route-map SETMETRIC out neighbor internalmap filter-list 1 out neighbor internalmap filter-list 2 in neighbor peer-group internalmap neighbor peer-group internalmap neighbor peer-group internalmap neighbor filter-list 3 in En la configuración que aparece a continuación se define para el mismo escenario un peer group (externalmap) que se aplica a todos los vecinos externos al router RTC. RTC# router bgp 300 neighbor externalmap peer-group neighbor externalmap route-map SETMETRIC neighbor externalmap filter-list 1 out neighbor externalmap filter-list 2 in neighbor remote-as 100 neighbor peer-group externalmap

19 neighbor remote-as 600 neighbor peer-group externalmap neighbor remote-as 200 neighbor peer-group externalmap neighbor filter-list 3 in En este caso, cada sesión BGP con cada vecino se define con la opción remote- fuer a del peer-group, ya que se trata de vecinos de otros AS y, por tanto, se utilizan as diferente ASN en cada caso. Además, se sobrescribe la política para los anuncios de entrada con el vecino asignándole la filter-list CIDR y direcciones agregadas Una de las características adicionales que soporta BGPv4 respecto a BGPv3 es CIDR ( Classless Interdomain Routing), que consiste en no considerar las direcciones IP divididas en clases (A, B o C), sino que cada dirección IP se define junto con un número decimal que indica el número de bits dedicados a la subred. Así, la dirección /16 equivale a La agregación de direcciones se utiliza para minimizar el tamaño de las tablas de encaminamiento, ya que a la hora de anunciar varias redes los routers resumen dicha información agrupando prefijos con partes comunes en superprefijos. En el ejemplo que aparece a continuación, el router RTB genera el anuncio de la red y el router RTC propagará dicha dirección a RTA como una dirección agregada en el prefijo RTB# router bgp 200 neighbor remote-as 300 network RTC# router bgp 300 neighbor remote-as 200

20 neighbor remote-as 100 network aggregate-address Existen varios comandos para la agregación de rutas. El comando utilizado en el ejemplo anterior es aggregate-address address mask. Este comando sirve para anunci ar el prefijo de la ruta indicada y también el resto de prefijos específicos comprendidos en el prefijo anterior que el router tenga en su tabla de encaminamiento BGP. Así, en el ejemplo previo se propagará la ruta y no se evitará que se propague también a RTA la ruta Un aspecto a tener en cuenta es que no router no puede agregar una dirección si no dispone de un prefijo específico de esa dirección en su tabla de encaminamiento BGP. Por ejemplo, el router RTB no podría generar la dirección agregada si no dispone de una entrada más específica en su tabla BGP, la cual debe ser añadida por anuncios entrantes de otros AS, por redistribución de un protocolo IGP o de una ruta estática, o mediante el uso del comando network (como ocurre en el ejemplo anterior). En el caso de que se quiera que el router RTC propague sólo la ruta y no los prefijos más específicos, sería necesario utilizar la opción siguiente: aggregate-address address mask summary-only De este modo, el comando aggregate summary-only propagará el prefijo y suprimirá el resto de prefijos específicos para ser anunciados. Sin embargo, en el caso de que se haya añadido un prefijo específico mediante el comando network, dicho prefijo será también anunciado a pesar de haber utilizado la opción summary-only en la agregación. En el caso de que se quieran suprimir más rutas específicas cuando se realiza una agregación, se puede definir un route map para suprimir las rutas específicas a anunciar de una manera selectiva. El comando que se debe usar para aplicar un route map a los anuncios de las direcciones agregadas es el siguiente: aggregate-address address-mask suppress-map map-name. Como ejemplo se puede suponer en el escenario anterior que se desea agregar la dirección , suprimir la ruta específica y permitir el anuncio del resto de rutas específicas ( , por ejemplo). Para este caso se podría la siguiente configuración: RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 100 network route-map CHECK permit 10 match ip address 1 access-list 1 deny access-list 1 permit aggregate-address suppress-map CHECK

21 Otra forma para aplicar un route map es mediante el comando aggregateaddress address mask attribute-map map-name, el cual permite modificar los atributos de las rutas agregadas antes de ser enviadas. El route map siguiente se aplica para modificar el origen de las rutas agregadas al valor IGP antes de ser anunciadas. route-map SETMETRIC set origin igp aggregate-address attribute-map SETORIGIN Anteriormente se ha señalado que no era posible suprimir una ruta específica si ésta era originada en el mismo router que realiza la agregación mediante el comando networ k, incluso si se utilizaba la opción aggregate summary-only. De este modo, en el sigui ente ejemplo el router RTB no puede generar, en principio, el prefijo sin generar la ruta porque dicha ruta específica es local al AS 200 y es el propio router RTB quien la genera. Una primera solución consiste en usar una ruta estática para la ruta agregada y redistribuirla en BGP. El inconveniente de esta solución es que la ruta agregada se anunciará con un atributo ORIGIN con valor INCOMPLETE (?). La configuración correspondiente a esta solución sería la siguiente: RTB# router bgp 200 neighbor remote-as 300 redistribute static ip route null0 Una solución posible en suma a la adición de una ruta estática es indicar la ruta agregada mediante el comando network, lo cual permitirá que el origen de esta ruta sea un protocolo IGP. La configuración sería como la siguiente: RTB# router bgp 200 network mask neighbor remote-as 300 redistribute static ip route null0 Otra opción del comando aggregate-address utilizada en la agregación de rutas es as-set, la cual permite anunciar el prefijo agregado con información sobre los atributos AS_PATH de las rutas específicas para evitar pérdida de información. Esta opción reduce el tamaño del atributo AS_PATH añadiendo sólo los ASN una sola vez. En el siguiente ejemplo, el router RTC obtiene la ruta del router

22 RTA y la ruta de RTB. Suponiendo que RTC quiere agregar dichas rutas en la dirección /8 y enviarla a RTD, el router RTD no podrá saber en principio cuál es el origen de cada dicha ruta. Sin embargo, gracias a la opción as-set se fuerza a RTC a originar información del AS_PATH en cada anuncio. RTB# router bgp 200 network neighbor remote-as 300 RTA# router bgp 100 network neighbor remote-as 300 RTC# router bgp 300 neighbor remote-as 200 neighbor remote-as 100 neighbor remote-as 400 aggregate summary-only aggregate as-set En el caso de que en la configuración del router RTC no se hubiese utilizado la opción as-set, el router RTD no sabría cuál es el origen real de la ruta /8 ya que ésta puede provenir de dos orígenes distintos (AS 100 y AS 200). Así, sin esta opción el router RTC enviaría el anuncio de la ruta agregada a RTD con un atributo AS_PATH igual a (300), como si la ruta hubiese sido generada por el AS 300. En cambio, con la opción as-set el atributo AS_PATH de la ruta agregada será igual a (100, 200), de forma que se indica que dicha ruta puede pertenecer a los AS 100 y Route Flap Dampening Una ruta que flapea consiste en una ruta inestable que va apareciendo como up o como down, o que va modificándose un atributo de ésta ( como el AS_PATH, por ejempl o). Esto puede ser debido a diversos factores como la inyección de rutas IGP dinámicamente en BGP, la inestabilidad de algunos enlaces o el cambio de política de encaminamiento. El flapeo de rutas se traduce en la generación de gran cantidad de mensajes BGP de tipo UPDATE, lo que implica un mayor consumo de ancho de banda y de recursos de CPU de los routers. Si el AS es un cliente, los flapeos dentro del AS afectarán al propio AS y al proveedor de servicio del AS. Por otra parte, si el AS es un ISP, los flapeos dentro del AS afectarán al AS y a otros ISP. Una forma de minimizar el efecto de las rutas inestables es mediante la sumarización o agregación de rutas, de forma que si se realiza la agregación de rutas en

23 el borde del AS se puede evitar que los cambios de una ruta relativa a una subred se propaguen fuera del AS, ya que se anuncia la supernet. Otra forma de evitar problemas de inestabilidad consiste en desligar los anuncios de una ruta hacia el exterior de la propia existencia de la ruta en el AS, para lo cual las rutas se inyectan hacia el exterior de forma estática en vez de redistribuyendo IGP en BGP. Por otro lado, otro mecanismo utilizado en BGP para reducir el alcance y la propagación de las inestabilidades de rutas es el dampening, el cual se aplica solamente a los anuncios de entrada E-BGP y que consiste en categorizar las rutas en dos grupos: ill-behaved y well-behaved. Cada vez que una ruta flapea se le penaliza, de manera que tras superar un cierto número de penalizaciones en un periodo de tiempo determinado ésta se suprime y no se anuncia a otros vecinos BGP. Una ruta puede seguir siendo penalizada aún cuando ya haya superado el umbral de supresión y no se esté anunciando. Por otra parte, la penalidad de una ruta va decayendo exponencialmente con el tiempo, de manera que la ruta puede volver a reutilizarse cuando su penalidad queda por debajo del límite de reuso. Además, las penalidades se reinician a cero cuando éstas caen por debajo de la mitad del límite de reuso. La siguiente gráfica representa la penalidad de una ruta respecto al tiempo, mostrando los límites de supresión y de reuso: La documentación que especifica el uso de penalizaciones es el RFC Los parámetros los elige quien penaliza, siendo los valores por defecto para los routers Cisco los siguientes: Incremento en 1000 cada flapeo (en 500 si cambian los atributos del anuncio). Umbral de supresión: 2000.

24 Umbral para reusar: 750. Tiempo medio: 15 min. Durante este tiempo la ruta no está suprimida, aunque sí puede ser penalizada si flapea (lo cual puede ocurrir cada 5 segundos). Tiempo máximo de supresión: 4 x tiempo medio. Cada 10 segundos se revisan las rutas para ver si alguna ruta puede pasar de suprimida a anunciarse si su número de penalizaciones correspondiente se ha reducido por debajo del límite de reuso. En el caso de que pase el tiempo máximo de supresión y no se haya reducido suficientemente el número de penalizaciones, la ruta deja de estar suprimida para poder ser anunciada. Inicialmente, el mecanismo de dampening está desactivado por defecto. Los siguientes comandos se utilizan para controlar el dampening de rutas en un router Cisco: bgp dampening: Activa el mecanismo de dampening en el router, el cual se aplica a las rutas aprendidas por EBGP y no por IBGP. no bgp dampening: Desactiva el dampening en el router. bgp half-life-time reuse supress maximum-suppress-time: Establece el valor de todos los parámetros al mismo tiempo. El rango posible para cada parámetro es el siguiente: o Tiempo medio de vida (half-life-time): 1-45 min. o Umbral de reuso (reuse-value): o Umbral de supresión (suppress-value): o Tiempo máximo de supresión (max-suppress-time): A continuación aparece un ejemplo de configuración en el que se usa el mecanismo de dampening: RTB# hostname RTB interface Serial0 ip address

25 interface Serial1 ip address router bgp 100 bgp dampening network neighbor remote-as 300 RTD# hostname RTD interface Loopback0 ip address interface Serial0/0 ip address router bgp 300 network neighbor remote-as 100 El mecanismo de route dampening está configurado en el router RTB con los valores por defecto para los distintos parámetros. Suponindo en primer lugar que el enlace EBGP con RTD es estable, la tabla BGP de RTB sería como sigue: RTB#show ip bgp BGP table version is 24, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *> i *> i Para simular un flapeo de una ruta se va a ejecutar el comando clear ip bgp en RTD, de modo que este router no anuncia dicha ruta a RTB. De este modo, la tabla BGP de RTB quedaría de la siguiente forma: RTB#show ip bgp BGP table version is 24, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path h i *> i En la tabla anterior se puede ver cómo la entrada para la ruta aparece con el estado h (history), que significa que no se dispone de un camino mejor para dicha ruta, pero que la información de flapping (es decir, las penalidades) todavía se conservan. Dicha información puede verse mediante el siguiente comando:

26 RTB#show ip bgp BGP routing table entry for , version 25 Paths: (1 available, no best path) 300 (history entry) from ( ) Origin IGP, metric 0, external Dampinfo: penalty 910, flapped 1 times in 0:02:03 En este caso la ruta tiene una penalidad que es inferior al límite de supresión (cuyo valor es 2000 por defecto), de manera que esta ruta todavía no ha sido suprimida. Si se producen más flapeos en dicha ruta se podría ver lo siguiente: RTB#show ip bgp BGP table version is 32, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *d i *> i RTB#show ip bgp BGP routing table entry for , version 32 Paths: (1 available, no best path) 300, (suppressed due to dampening) from ( ) Origin IGP, metric 0, valid, external Dampinfo: penalty 2615, flapped 3 times in 0:05:18, reuse in 0:27:00 En este último caso la ruta ha sido suprimida (dampened). Esta rutapodrá ser reutilizada cuando el valor de la penalidad sea inferior al límite de reuso (750 por defecto). Si la penalidad sigue disminuyendo y alcanza un valor inferior a la mitad del límite de reuso (750/2=350), toda la información referente a las penalidades será borrada. Los siguientes comandos se utilizan almacenadas sobre el flapeo de rutas: para mostrar y borrar las informaciones show ip bgp flap-statistics: Muestra las estadísticas sobre el flapeo de todas las rutas. show ip bgp-flap-statistics regexp <regexp>: Muestra las estadísticas sobre el flapeo de todos los caminos que cumplen la expresión regexp. show ip bgp flap-statistics filter-list <list>: Muestra las estadísticas sobre el flapeo de todos los caminos que pasan el filtro indicado. show ip bgp flap-statistics A.B.C.D m.m.m.m: Muestra las estadísticas del fapleo de una entrada determinada. show ip bgp neighbor [dampened-routes] [flap-statistics]: Muestra las estadísticas del flapeo de todas las rutas aprendidas de un vecino. clear ip bgp flap-statistics: Borra las estadísticas de flapeo de todas las rutas guardadas en la tabla BGP del router.

27 clear ip bgp flap-statistics regexp <regexp>: Borra todas las estadísticas sobre el flapeo de todos los caminos que cumplen la expresión regexp. clear ip bgp flap-statistics filter-list <list>: Borra todas las estadísticas sobre el flapeo de todos los caminos que pasan el filtro indicado. clear ip bgp flap-statistics A.B.C.D m.m.m.m: Borra las estadísticas del fapleo de una entrada determinada. clear ip bgp A.B.C.D flap-statistics : Borra las estadísticas de flapeo de todas las rutas aprendidas de un vecino EBGP.