Chapter 4. Local minimisation of lattice energy – the CrystalOptimizer algorithm
4.4. Algorithm validation, Results and Discussion
4.4.4. Application to single component crystals
Lab. 7 - BGPv4: Route Reflector y Confederation
7.1. Objetivo de la práctica
El objetivo de esta práctica es aprender a configurar AS sin el requisito de malla completa (full-mesh) para las sesiones iBGP. Para ello se aprenderán los dos métodos conocidos: router reflector y confederation.
7.2. Introducción a iBGP
Uno de los requisitos que se han visto es que se debe establecer una malla completa de sesiones iBGP entre router BGP (Figura 21). En otras palabras, cada router BGP en un AS debe tener sesiones iBGP con todos los otros routers BGP del AS. Esto hace que no pueda haber ningún bucle en iBGP porque se exige que:
• toda la información que se envía por iBGP se aprende directamente desde el router que ha obtenido la información por eBGP
• toda información recibida por iBGP solo se puede reenviar por eBGP.
Figura 21: Malla completa de sesiones iBGP.
Si N es el número de routers BGP de un AS, el requisito de full-mesh hace que cada router deba mantener N-1 sesiones iBGP activas al mismo tiempo por un total de N(N-1)/2 sesiones iBGP para todo el AS. Existen dos métodos para relajar este requisito que son Route Reflector y Confederation que veremos a continuación.
7.3. Confederation
La implementación de BGP con confederación reduce la full-mesh de iBGP dentro de un AS. El truco consiste en dividir un AS en múltiples sub-ASes (confederación de AS). Cada sub-AS se comporta como un AS con internamente una full- mesh de iBGP pero solo algunas sesiones eBGP con el resto de sub-ASes del AS. Esta sesión eBGP realmente son interna al AS y se les suele llamar eiBGP (o tambien confederation BGP, cBGP). Esta configuración permite que atributos internos al AS como next hop, metric y local preference se mantengan para todos los sub-ASes. De cara al exterior, el AS se seguiría viendo como un único AS.
Lab. 7 - BGPv4: Route Reflector y Confederation
Para configurar una confederación se necesitan dos comandos. El primero es “bgp confederation identifier AS-number”
donde AS-number es su número de AS. El segundo es “bgp confederation peers AS1-number AS2-number etc.”, donde
ASn-number son los números que identifican los sub-ASes que hacen parte de la confederación. Generalmente para estos
sub-ASes se usan número de AS del rango privado 64512-65535.
En el ejemplo de la Figura 22, la configuración del router R1 sería la siguiente. Se supone que las direcciones de loopback se asignan siguiendo el criterio 10.100.X.1/30 donde X es el número del router (no obstante, el comando update-source
dummy0 se omite para simplificar el ejemplo).
R1(config)# router bgp 65001 -> pertenece al sub-AS privado 65001 R1(config-router)# bgp confederation identifier 100 -> número AS real
R1(config-router)# bgp confederation peers 65002 -> está conectado al sub-AS 65002 R1(config-router)# neighbor 10.0.3.1 remote-as 300 -> eBGP con el AS300
R1(config-router)# neighbor 10.100.2.1 remote-as 65001 -> iBGP del mismo sub-AS R1(config-router)# neighbor 10.100.3.1 remote-as 65001 -> iBGP del mismo sub-AS R1(config-router)# neighbor 10.100.4.1 remote-as 65002 -> eiBGP con otro sub-AS
Para el router R4.
R4(config)# router bgp 65002
R4(config-router)# bgp confederation identifier 100
R4(config-router)# bgp confederation peers 65001 65003 -> está conectado al sub-AS 65001 y 65003 R4(config-router)# neighbor 10.0.2.1 remote-as 200
R4(config-router)# neighbor 10.100.1.1 remote-as 65001 R4(config-router)# neighbor 10.100.5.1 remote-as 65002 R4(config-router)# neighbor 10.100.6.1 remote-as 65003
Para el router R8.
R8(config)# router bgp 65003
R8(config-router)# bgp confederation identifier 100 R8(config-router)# neighbor 10.0.4.1 remote-as 400 R8(config-router)# neighbor 10.100.6.1 remote-as 65003 R8(config-router)# neighbor 10.100.7.1 remote-as 65003 R8(config-router)# neighbor 10.100.9.1 remote-as 65003
Y por ultimo el R418.
R41(config)# router bgp 400
R41(config-router)# neighbor 10.0.4.2 remote-as 100 -> un router externo ve el AS como 100
7.4. Route Reflection
Otra solución posible para relajar el requisito de full-mesh para iBGP es usar Route Reflector (RR). En este caso se divide el AS en clusters y para cada cluster se elige un router BGP que haga de router RR3. El resto de routers que no son RR se
llaman clientes. Dentro de cada cluster se configuran sesiones iBGP entre clientes y RR, pero no entre clientes (se configura una topología a estrella de iBGP con RR como centro). Entre RR de cluster diferente se configuran sesiones iBGP a malla completa. La característica de los router RR es que estos pueden reenviar mensajes recibidos por iBGP a otros vecinos iBGP, mientras para los clientes sigue valida la regla que no pueden. En concreto el router RR sigue estas reglas al recibir un mensaje BGP:
• Si el mensaje BGP proviene de un vecino no cliente (por ejemplo otro RR), entonces el RR la refleja a todos sus clientes dentro de su cluster.
• Si el mensaje BGP proviene de un cliente, el RR lo refleja a todos los vecinos clientes y no clientes. • Si el mensaje BGP se aprende de un vecino eBGP, éste se envía a todos los vecinos clientes y no clientes.
Lab. 7 - BGPv4: Route Reflector y Confederation
En el ejemplo de la Figura 23, el router R4 es el único RR de este AS. Por lo tanto todos los demás router BGP son clientes y deben establecer una sesión iBGP con el RR. Cuando un cliente recibe un mensaje eBGP de otro AS, este lo reenvia solamente al RR. El RR a su vez, enviará este mensaje a los otros AS por eBGP como es habitual pero tambien a todos los demás clientes de su mismo AS (por eso se llama reflector). Como los clientes reciben el mensaje por iBGP, solo pueden reenviarlo por eBGP.
Para esta configuración se necesita añadir en la configuración de los vecinos iBGP del router elegido como RR el comando “neighbor @IP-neighbor route-reflector-client”.
En el ejemplo de la Figura 23, la configuración del router R4 sería la siguiente. Como en el caso anterior se supone que las direcciones de loopback se asignan siguiendo el criterio 10.100.X.1/30 donde X es el número del router (el comando
update-source dummy0 se omite para simplificar el ejemplo).
R4(config)# router bgp 100
R4(config-router)# neighbor 10.0.2.1 remote-as 200
R4(config-router)# neighbor 10.100.1.1 remote-as 100 -> iBGP con otro router
R4(config-router)# neighbor 10.100.1.1 route-reflector-client -> se especifica que es un cliente R4(config-router)# neighbor 10.100.2.1 remote-as 100
R4(config-router)# neighbor 10.100.2.1 route-reflector-client R4(config-router)# neighbor 10.100.3.1 remote-as 100
R4(config-router)# neighbor 10.100.3.1 route-reflector-client
Y para el router R3.
R3(config)# router bgp 100
R3(config-router)# neighbor 10.0.3.1 remote-as 300
R3(config-router)# neighbor 10.100.4.1 remote-as 100 -> iBGP con el RR
En el ejemplo de la Figura 24 hay tres routers RR y por lo tanto se han definido tres clusters. Dentro de cada clusters, los clientes mantienen una sesión iBGP con su RR, mientras los RR mantienen una full-mesh entre ellos.
Figura 24: Ejemplo de tres Route Reflector en un AS.
En este caso la configuración del router R1 sería la siguiente.
R1(config)# router bgp 100
R1(config-router)# neighbor 10.0.3.1 remote-as 300 R1(config-router)# neighbor 10.100.2.1 remote-as 100
R1(config-router)# neighbor 10.100.2.1 route-reflector-client R1(config-router)# neighbor 10.100.3.1 remote-as 100
R1(config-router)# neighbor 10.100.3.1 route-reflector-client
R1(config-router)# neighbor 10.100.4.1 remote-as 100 -> iBGP con otro RR R1(config-router)# neighbor 10.100.6.1 remote-as 100 -> iBGP con otro RR
La del R4 sería la siguiente.
R4(config)# router bgp 100
R4(config-router)# neighbor 10.0.2.1 remote-as 200 R4(config-router)# neighbor 10.100.1.1 remote-as 100 R4(config-router)# neighbor 10.100.6.1 remote-as 100
Y finalmente para R8.
R8(config)# router bgp 100
R8(config-router)# neighbor 10.0.4.1 remote-as 400 R8(config-router)# neighbor 10.100.6.1 remote-as 100
Lab. 7 - BGPv4: Route Reflector y Confederation
Cabe destacar que para evitar bucles, BGP define dos nuevos atributos cuando se usa RR:
• Originator-id: Este es un atributo opcional. Un RR crea este atributo. Su función es guardar el identificador del router (RID) que originó la ruta. De este modo, si debido a una inadecuada configuración una ruta es anunciada a su router origen, dicha información será ignorada.
• Cluster-list: Atributo de una ruta en el que se van añadiendo los cluster-id del cluster al que pertenece cada RR
por el que va pasando la ruta. Su objetivo y funcionamiento es parecido al caso de AS-path. Es decir es útil para evitar bucles en el caso de múltiples 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.
7.5. Realización de la práctica
Figura 25: Red de la práctica.
Configurar la red de la Figura 25 siguiendo los pasos que se indican a continuación (es importante respetar el orden indicado):
1. Dividirse en 2 sub-grupos, cada uno con 6 PCs. Un grupo se ocupará de la configuración del AS 100, AS 200 y mitad del AS 1 y el otro grupo de la configuración del AS 300, AS 400 y la otra mitad del AS 1.
2. Configurar las direcciones IP en todas las interfaces de la red que aparece en la figura de forma que hay conectividad entre dos interfaces vecinas.
3. Configurar encaminamiento interno (OSPF) en los routers del AS 1. Comprobar que dos routers no vecinos del AS 1 pueden hacerse ping. Fijarse que no hace falta OSPF en los AS 100, 200, 300 y 400 ya que solo hay 1 router.
4. Activar el encaminamiento interno del BGP en AS 1, configurando R3 y R1 como routers RR para las sesiones iBGP. Configurar R2 y R4 como clientes. Comprobar que las sesiones están creadas.
5. Activar eBGP entre AS 1 y AS 100 y 200, lo mismo entre AS 1 y AS 300 y 400. Comprobar que todo funciona como esperado.
6. Verificar las entradas en las tablas de encaminamiento BGP y comprobar que los hots pueden hacerse ping entre ellos.