6.

I-BGP
Cada router pasarela establece una sesin I-BGP con el resto de pasarelas del mismo AS. Aunque no exista conectividad fsica directamente, la sesin I-BGP se puede establecer a travs de un camino indirecto gracias al resto de routers del AS, los cuales utilizan un protocolo IGP para el encaminamiento. Las pasarelas de un mismo AS no establecern sesiones I-BGP mediante direcciones fsicas, sino mediante direcciones de bucle o loopback (neighbor {ip address | peer-group} update-source loopback0). El uso de direcciones loopback permite la conexin a una sola direccin virtual de un router que cuenta con varias interfaces y direcciones fsicas, de manera que dicha conexin sea independiente a los fallos de una interfaz fsica. El protocolo IGP correspondiente es el encargado de indicar a una pasarela cmo alcanzar la direccin virtual del otro extremo. Un aspecto a tener en cuenta en el caso de que un router anuncie va IBGP informacin de rutas aprendidas va EBGP es que el atributo NEXT-HOP de cada ruta se mantiene. De este modo, surgir un problema si una ruta proviene de un router externo al AS, ya que el router interno que aprende dicha ruta mediante IBGP no sabr cmo llegar al router externo. Por ello, en los routers frontera que se encargan de intercambiar informacin de encaminamiento con otros routers de otros AS se utliza el comando neighbor @IP_vecino_IBGP next-hop-slf. Con este comando se obliga a que todos los anuncios que dicho router hace va IBGP tengan como NEXT_HOP su propia direccin y no la del router del AS externo. Para que dentro de un AS todos los routers BGP conozcan todas las redes propagadas va IBGP, es necesario que el AS se encuentre totalmente mallado (fully meshed), es decir, que se establezcan sesiones IBGP entre todos los routers BGP. En consecuencia, para n routers se necesitarn n(n-1)/2 sesiones I-BGP, lo cual puede resultar inviable en un AS con un nmero considerable de routers. Por ello, para hacer escalable el protocolo I-BGP y reducir el nmero de sesiones I-BGP dentro de un sistema autnomo se utilizan dos tcnicas: BGP Confederations y Route Reflectors.

6.1.

Confederacin BGP

Dentro de un AS es posible definir AS internos denominados confederaciones, los cuales se comportan como un solo AS general de cara al exterior. La finalidad de una confederacin BGP es reducir el mallado I-BGP dentro de un AS. Para ello, se define la confederacin como el conjunto de redes y routers del AS principal, el cual se divide en diversos AS. De este modo, en el interior de cada AS interno se utilizar un mallado total (fully meshed) entre sus routers de borde y cada AS se conectar con el resto de AS dentro de la confederacin. Aunque los routers de borde de AS diferentes dentro de la confederacin intercambian informacin de encaminamiento mediante sesiones E-BGP, dicha informacin se intercambia como si se tratase de sesiones I-BGP, es decir, que se preservan atributos como NEXT_HOP, METRIC y LOCAL_PREF. Adems, desde el

punto de vista de los AS externos a la confederacin, el grupo de AS de la confederacin se ven como un solo AS. Para indicar la confederacin a la que pertenece un router BGP se utiliza el siguiente comando: bgp confederation identifier autonomous-system. El identificador de confederacin ser el ASN con el que el resto de AS externos van a ver al grupo de AS que forman la confederacin. Por otro lado, para indicar cada uno de los subsistemas con los que el router puede establecer sesiones BGP y que forman parte de su misma confederacin se utiliza el comando siguiente: bgp confederation peers autonomous-system [autonomous-system]. El escenario que aparece a continuacin muestra un ejemplo de uso de una confederacin para reducir el mallado en un AS con muchos routers de borde:

En este caso se supone que se dispone del AS 500, al cual pertenecen nueve routers de borde con sesiones E-BGP con otros routers de borde de otros AS. Si no se utilizase una confederacin en la que se divida el AS 500 en otros AS, cada router tendra nueve sesiones establecidas (ocho sesiones I-BGP con el resto de routers de borde del AS 500 y una sesin E-BGP con un vecino de otro AS). La solucin al problema del exceso de sesiones I-BGP puede conseguirse definiendo el AS 500 como una confederacin, dentro de la cual se tienen mltiples AS (AS 50, AS 60 y AS 70). El identificador de la confederacin tendr el valor 500, de modo que el resto de AS externos ver al conjunto de AS de la confederacin como un AS con nmero 500.

La configuracin de los routers RTC, RTD y RTA en este escenario sera la siguiente:

RTC# router bgp 50 bgp confederation identifier 500 bgp confederation peers 60 70 neighbor 128.213.10.1 remote-as 50 (conexin I-BGP dentro del AS 50) neighbor 128.213.20.1 remote-as 50 (conexin I-BGP dentro del AS 50) neighbor 129.210.11.1 remote-as 60 (conexin BGP con el AS 60 interno) neighbor 135.212.14.1 remote-as 70 (conexin BGP con el AS 70 interno) neighbor 5.5.5.5 remote-as 100 (conexin E-BGP con el AS 100 externo) RTD# router bgp 60 bgp confederation identifier 500 bgp confederation peers 50 70 neighbor 129.210.30.2 remote-as 60 (conexin I-BGP dentro del AS 60) neighbor 128.213.30.1 remote-as 50 (conexin BGP con el AS 50 interno) neighbor 135.212.14.1 remote-as 70 (conexin BGP con el AS 70 interno) neighbor 6.6.6.6 remote-as 600 (conexin E-BGP con el AS 600 externo) RTA# router bgp 100 neighbor 5.5.5.4 remote-as 500

(RTA no conoce los AS 50, 60 y 70, sino que slo conoce el AS 500).

6.2.

BGP Route Reflectors

Una regla a cumplir por los routers BGP para evitar bucles es que no deben anunciar una ruta a un vecino I-BGP si dicha ruta la prendi de otro vecino mediante IBGP. Por esto, en un AS se debe cumplir que cada router de borde debe tener establecida una sesin I-BGP con el resto de routers de borde de su mismo AS. Como excepcin a la regla anterior, un router con la propiedad de Route Reflector puede anunciar una ruta aprendida por I-BGP a otro vecino I-BGP, lo cual permite reducir considerablemente el nmero de sesiones I-BGP en un AS. La siguiente opcin del comando neighbor convierte a un router en Route Reflector y la IP del vecino indicado corresponde al cliente de dicho Route Reflector: neighbor IP_vecino route-reflector-client. La combinacin de un RR y sus clientes se denomina cluster. El resto de vecinos I-BGP no indicados con el comando anterior en la configuracin del RR son considerados como no clientes, por lo que el RR no les anunciar mediante I-BGP las rutas aprendidas de los clientes I-BGP (aunque s podra hacerlo mediante IGP). El despliegue de los route reflectors se lleva a cabo dividiendo el backbone en varios grupos (clusters), de manera que cada grupo disponga de un RR al menos (o de mltiples para redundancia) y mltiples clientes. Los RR establecen una malla completa I-BGP entre ellos y pueden ser configurados de forma jerrquica, de forma que en un cluster se pueden tener RRs clientes de otros RRs de un nivel superior.

El siguiente ejempo muestra un caso de un RR y sus clientes dentro de un AS:

En una situacin normal, entre los routers RTA, RTB y RTC del AS 100 existira un mallado total, es decir, cada uno de ellos tendra establecida una sesin IBGP con los otros dos. Sin embargo, mediante el uso del concepto de Route Reflector, el router RTC se puede elegir como RR. De esta forma, los routers RTA y RTC sern los clientes de RTC y no necesitarn establecer una sesin I-BGP entre ellos, sino que se anunciarn rutas indirectamente a travs de las sesiones I-BGP que establezcan con RTC. Por ello, en la configuracin de RTC se utilizar el comando neighbor routereflector-client indicando las direcciones IP de los clientes RTA y RTB. Los routers RTA, RTB y RTC formarn as un cluster con un solo RR dentro del AS 100. En un sistema autnomo puede existir ms de un RR, de manera que cada RR trate al resto de RR como vecinos I-BGP. En una configuracin simple, un AS se divide en mltiples clusters, configurndose cada RR como no cliente del resto de RR, de forma que los clientes de un cluster no establezcan sesiones I-BGP con otros vecinos IBGP fuera del cluster.

En el siguiente ejemplo, los routers RTA, RTB y RTC forman un solo cluster con RTC como RR, RTA y RTB como clientes de RTC y el resto de vecinos I-BGP como no clientes. Del mismo modo, el router RTD es un RR para sus clientes RTE y RTF, mientras que el router RTG es un RR de un tercer cluster. As, entre los routers RTC, RTD y RTG existe un mallado I-BGP total, mientras que no ocurre as dentro de cada cluster, en los que cada router I-BGP establece una sesin slo con el RR correspondiente.

A continuacin se muestra la configuracin de los routers RTC, RTB y RTD:

RTC# router bgp 100 neighbor 2.2.2.2 neighbor 2.2.2.2 neighbor 1.1.1.1 neighbor 1.1.1.1 neighbor 7.7.7.7 neighbor 4.4.4.4 neighbor 8.8.8.8

remote-as 100 route-reflector-client remote-as 100 route-reflector-client remote-as 100 remote-as 100 remote-as 200

RTB# router bgp 100 neighbor 3.3.3.3 remote-as 100 neighbor 12.12.12.12 remote-as 300 RTD# router bgp 100 neighbor 6.6.6.6 neighbor 6.6.6.6 neighbor 5.5.5.5 neighbor 5.5.5.5 neighbor 7.7.7.7

remote-as 100 route-reflector-client remote-as 100 route-reflector-client remote-as 100

neighbor 3.3.3.3 remote-as 100

Cuando un RR recibe una ruta, el RR realizar las siguientes acciones dependiendo de la forma en la que se aprendi la ruta: Si la ruta proviene de un vecino no cliente, entonces el RR la refleja a todos sus clientes dentro del cluster. Si la ruta proviene de un cliente, el RR la refleja a todos los vecinos no clientes y tambin a los clientes. Si la ruta se aprende de un vecino E-BGP, sta se enva a todos los vecinos clientes y no clientes.

El motivo de no propagar rutas aprendidas de un vecino I-BGP a otro vecino IBGP era evitar bucles en el encaminamiento. Para solucionar este problema, los RR utilizan las siguientes informaciones: Originator-id: Se trata de un atributo opcional de cuatro bytes creado por un RR. Su funcin es guardar el identificador del router (RID) que origin la ruta. De este modo, si debido a una inadecuada configuracin una ruta es anunciada a su router origen, dicha informacin ser ignorada. Cluster-list: Atributo de una ruta en el que se van aadiendo los cluster-id del cluster al que pertenece cada RR por el que va pasando la ruta. Este atributo es til para evitar bucles en el caso de mltiples RR en el interior de un mismo cluster, ya que un RR puede detectar si su cluster-id se encuentra ya en la lista y evitar as un bucle ignorando la ruta.

En general, un cluster suele disponer de un solo RR y el router-id del RR sirve para identificarlo. No obstante, para aumentar la redundancia y evitar que todo el encaminamiento I-BGP deje de funcionar en caso de fallo del RR, se pueden configurar ms de un RR dentro de un mismo cluster. Todos los RR en el mismo cluster deben de configurarse con un cluster-id (4 bytes), de manera que un RR pueda reconocer los anuncios que provienen de otros RR en el mismo cluster. Para configurar el cluster-id de un router RR (que pertenezca a un cluster con otros RRs) se utiliza el siguiente comando bgp route-reflector cluster-id. Una cluster-list es una secuencia de los cluster-id de los clusters al que pertenecen los RRs por los que la ruta ha pasado. Cuando un RR refleja una ruta desde sus clientes a sus no clientes fuera del cluster, ste aade su cluster-id a la cluster-list o crea una nueva cluster-list para dicha ruta en el caso de que no exista ninguna. Gracias a este atributo un RR puede identificar si una ruta que proviene del exterior produce un bucle al volver al mismo cluster debido a una inadecuada configuracin. As, si el RR encuentra el cluster-id de su cluster en la cluster-list de la ruta, dicha ruta es ignorada.

En el siguiente escenario, los routers RTD, RTE, RTF y RTH pertenecen al mismo cluster, siendo los routers RTD y RTH ambos RRs del mismo cluster. En dicho escenario se puede ver como el router RTH establece una malla total con todos los routers RRs tanto de su cluster como del resto de clusters. La ventaja de esta redundancia de RRs es que en el caso de que RTD fallase, RTH mantendra el funcionamiento del encaminamiento I-BGP en el cluster. A continuacin se muestra la configuracin de los routers RTH, RTD, RTF y RTC:

RTH# router bgp 100 neighbor 4.4.4.4 remote-as 100 neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 9.9.9.9 remote-as 300 bgp route-reflector 10 (cluster-id)

RTD# router bgp 100 neighbor 10.10.10.10 remote-as 100 neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 11.11.11.11 remote-as 400 bgp route-reflector 10 (cluster-id)

RTF# router bgp 100 neighbor 10.10.10.10 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 13.13.13.13 remote-as 500

RTC# router bgp 100 neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 route-reflector-client neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-reflector-client neighbor 4.4.4.4 remote-as 100 neighbor 7.7.7.7 remote-as 100 neighbor 10.10.10.10 remote-as 100 neighbor 8.8.8.8 remote-as 200

Normalmente, en un AS suelen existir routers que no comprenden el concepto de Route Refletor, es decir, que no pueden ser configurados como RR. Estos routers se denominan routers convencionales, los cuales pueden coexistir con los RRs pudiendo formar parte de un grupo de clientes o de no clientes de un RR. De este modo, entre los routers convencionales y los RRs de un AS se establece un mallado I-BGP completo como si de routers normales se tratase. En el siguiente ejemplo, los routers RTD, RTE y RTF soportan el concepto de RR, mientras que RTC, RTA y RTB son lo que se denomina routers convencionales. En el AS 100 se tiene en principio un cluster con RTC como RR y los routers RTA y RTB como sus clientes. Entre RTC y los routers convencionales existir un mallado I-BGP completo, mientras que los routers clientes slo establecern sesiones I-BGP con RTC.

La siguiente configuracin corresponde a los routers RTD y RTC:

RTD# router bgp 100 neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 3.3.3.3 remote-as 100 neighbor 2.2.2.2 remote-as 100 neighbor 1.1.1.1 remote-as 100 neighbor 13.13.13.13 remote-as 300

RTC# router bgp 100 neighbor 4.4.4.4 remote-as 100 neighbor 2.2.2.2 remote-as 100 neighbor 1.1.1.1 remote-as 100 neighbor 14.14.14.14 remote-as 400

En el escenario anterior, se podra actualizar uno de los routers convencionales para que funcione como RR y formar as otro cluster, eliminando entonces el mallado I-BGP completo. En este caso, los dems routers convencionales seran los clientes, de manera que no necesitaran ser actualizados ya que los routers clientes no necesitan soportar el concepto de RR.