BGP Lab1

Espero que para la parte de los atributos revisen la PPT de BGP (Attributes y Best Path
Selection) (Weight, Local Preference ,AS-Path, Multi Exit Discriminator) demostrare un
ejemplo para cumplir los requerimientos 7 y 8 con los 4 atributos mencionados.

Requerimientos del Lab1:

0-.Se deber declarar bajo EIGRP cada una de las interfaces de los dispositivos que
se encuentran delimitados por el color morado en el diagrama, a excepcin de las
direcciones de Loopbacks de R1.

1-.R1 debe ser el Route Reflector solo para R3 y R5

2-.Se deben declarar las redes Loopbacks de R1 dentro del ASN:64520

3-.R6 y R7 deben correr autenticacin va BGP con password Cisco123

4-.R6 debe generar estticamente una ruta por default apuntando a R4

5-.R5 debe generar una ruta por default va BGP hacia R7

6-. R7 debe summarizar los prefijos de clase B dentro de la red 172.16.0.0/16 y

suprimir todas las redes que componen esta summarizacion.

7-. Para llegar a cualquier Red del ASN: 64535 todos los dispositivos del ASN:64520
debern preferir a R7 como punto de salida.

8-. Para llegar a cualquier Red del ASN: 64520 todos los dispositivos del ASN:64535
debern preferir a R4 como punto de salida.
1) El primer requerimiento indica que R1 debe ser el Route Reflector (RR) y
solo tener como clientes al R3 y R5.

Recuerden que la nica funcin del Route Reflector es evitar un Full Mesh entre
peers bajo el ASN, claro que pensado para topologas de mayor cantidad de
Routers que esta.

Partiremos configurando el ASN 64520 y estableciendo los peer entre R1 (RR) y

los Route-reflector-clients que seran (R3 y R5) asumiendo que ya se configuro
EIGRP 100 como protocolo que BGP utilizar para conocer todos los Routers del
ASN 64520. (Para establecer un peer en BGP se requiere conectividad de algn
modo)
Lo primero es levantar el ASN 64520 en R1 y declarar como Route Reflector clients a R3 y R5 en
donde R3 y R5 solo deben establecer un peer con el Route-Reflector y no entre ellos

Ahora desde R3 y R5 estableceremos un peer con el Route Reflector y adems con R2 y R4

(establecer un peer adems con R2 y R5 no es necesario pero para que se pueda ms adelante
observar las redes del ASN 64535 por diferentes caminos es necesario hacer esto en la prueba no
ser as, estarn todo bajo un RR o ser todo un full mesh).
El requerimiento 1 est realizado con las configuraciones anteriores.

Ahora se deben establecer los peer entre R1 con R2 y R4 (no-clients) o en otras palabras se debe
declarar los neighbors de manera normal sin el parmetro (Route-reflector-client).

En R2 debemos establecer tanto un peer con R1,R3,R4 y R5 por el contrario de los Route
reflectors clients que solo establecieron peer con el RR pero se realizo la excepcin de hacer peer
con R2 y R4 que no era necesario.
En R4 lo mismo peer con R1, R2, R3, R5

Recordar que el full mesh es requerido para que los Router que requieran recibir updates de redes
mediante BGP puedan obtenerlas, puesto que existe un mtodo de prevencin de Loops que
indica que un update recibido desde un peer iBGP no podr ser anunciado a otro peer iBGP.
Por ende si no tubieramos un Full mesh entre R1, R2 y R4 las redes declaradas por R1 solo seran
anunciadas a R2 pero R2 no se las anunciara a R4.

2) Se debe declarar las redes de R1 dentro del ASN 64520.

En primer lugar validaremos que R1 tiene como peer a R2, R3, R4 y R5

Este output nos indica que tenemos como neighbors a R2, R3, R4 y R5 que estn bajo el ASN
64520 el tiempo que los peer llevan establecidos y que tenemos 0 prefijos recibidos.

Ahora en R5 aplicaremos el mismo parmetro show ip bgp summary

Solo tenemos como peer a R1 (RR) y estamos aprendiendo 0 prefijos a ustedes les tendr que salir
a R2 , R3 y R4

Declararemos la Red Loopback 0 en R1 (1.1.1.1/32) para que la puedan conocer los dems peers.
Si verificamos en R5 o cualquier peer de R1 deberiamos estar recibiendo 1 prefijo el cual es el
declarado en R1 (1.1.1.1/32)

Validamos con esos parmetros que estamos recibiendo la Red declarada por R1. Este output ser
similar en R4 o R2 a diferencia que el next-hop ser 192.168.12.1.

3) Entre R6 y R7 deben estar corriendo autenticacin; antes de eso iremos a R4 y estableceremos

una sesin de EBGP con R6 y lo mismo en R5 declaremos a R7 como un peer EBGP (EBGP peer
recuerden que es cuando se establece un peer con un Router bajo otro ASN) y por ultimo entre R7
y R6 estableceremos una sesin IBGP y correremos autenticacin con el Password indicado.
Efectuaremos lo mismo entre R5 y R7

Como no hemos declarado la autenticacin enR6 se indica que existe un Badauth de parte de R6
aunque an no declaremos a R7 como neighbor.
4) El punto 4 es un requerimiento puesto que necesitamos una manera de retornar el trafico si
realizamos ping desde R1

Vemos que desde R1 no podemos alcanzar los segmentos o puntos de entrada a los Router R6 o
R7 puesto que el trfico no tiene idea como retornar al llegar a esos dispositivos.
Por eso se requieren rutas por default en esos dispositivos.

Realizamos la misma prueba de capa 3 desde R1 hacia R6 y tendremos ping pero como en R7 no
tenemos una manera de alcanzar a R1 el trfico no sabe cmo retornar.
5) R5 debe generar una ruta por default hacia R7 mediante BGP, esto solucionara el problema de
capa3 entre R1 y R7

Validamos que est llegando la ruta por default va BGP en R7

Probamos conectividad L3 nuevamente

6) R7 debe sumarizar los prefijos de clase B (172.16.x.x) y solo anunciar esa red (no las prefijos
ms especficos que fueron sumarizados dentro de el rango)

! Antes de realizar la sumarizacion declararemos todo lo directamente conectado dentro de BGP

tanto en R6 como en R7.

Validamos que estamos recibiendo las redes del ASN 64535 en R1

Ahora para cumplir con el requerimiento necesitamos hacer lo siguiente en R7

Recordar que con el parmetro summary-only suprimimos los prefijo ms especficos del rango,
sin el parmetro al final se declaran los prefijos especficos del rango sumariado y la red sumariada
tambin.

Para los puntos 7 y 8 se requiere manipular el trafico mediante los atributos en este caso los que
veremos sern ejemplos de (Weight, Local Preference, AS Path y MED)

En la ppt BGP part2 (se explican a resumen su uso y forma de aplicacin de estos atributos)

7) todos los prefijos del ASN64535 deben ser alcanzados por R7 desde el ASN 64520.

Antes que nada validaremos desde el punto de vista de R1 como conocemos las redes del
ASN64535
De este output podremos notar que todas las redes del ASN 64535 estn siendo alcanzables por el
R6, adems se puede observar algunos atributos con sus valores por default donde Metric es el
atributo (MED), Local preference que por default es 100 (a mayor mejor), El Weight 0 por default (
a mayor mejor), (AS path) por default es un ASN y hace referencia por cuantos sistemas
autnomos provienen los prefijos recibidos como estn a un ASN de distancia (analoga al nmero
de saltos en RIP) el ASN solo ser 1 que es el 64535.

En resumen y espero que lean el ppt de BGP part2

-Weight y Local Preference: (influenciamos el trfico de salida) y lo aplicamos de entrada (in)

-AS-Path y Multi-exit-Discriminator (MED) (influenciamos el trfico entrante y lo aplicamos de

salida (out)

Ahora Weight vs Local Preference es que el primero no es (transitivo) lo que quiere decir que solo
tiene significancia local en el Router que lo configure y no se transmite a otro Router o fuera del
ASN (en otras palabras el Router cuando reciba el trafico influenciado con el Weight, al pasar esos
prefijos a otro Router este remover el Weight configurado por l y lo dejara por default que es 0).

En cambio local preference es (transitivo) por ende se propagara a todo el ASN si influenciamos
algo.
Lo mismo para AS-Path (transitivo) y Med (no-transitivo).

Entonces como el Weight y el MED no son transitivos para estos ltimos requerimientos
configuraremos un ejemplo de AS-Path y con Local-Preference (hare un ejemplo de todos modos
con Weight y MED)

Ejemplo con Weight:

Si nos vamos a R2 y verificamos como estamos alcanzando el ASN 64535

Por ejemplo el prefijo 6.6.6.6/32 lo alcanzamos por la R6 puesto que por lgica esta mas cerca de
R2 ahora si quisiramos manipular en funcin del Weight para que ahora prefiera salir por R7
aumentaremos el valor del weight para ese prefijo.
En resumen lo que se est haciendo en este punto es clasificar el trfico o prefijo en este caso
6.6.6.6/32 con una prefix-list que es lo mismo que una ACL pero permite hacer match al /x.
Cuando se detecte este prefijo configrale un WEIGHT de 222 que es mejor que el por default 0.
Por ltimo el Route-map se lo aplicamos al neighbor por el cual estamos recibiendo ese prefijo
en este caso como tenemos 2 alternativas (R6 o R7) se lo aplicaremos a R7 de entrada (in) para
influenciar la salida a ese prefijo por R7. Pero como no es transitivo el Weight solo esto aplicara
para R2.
Si veo el mismo output en R1 veremos que este prefiere la ruta por R6 que por R7 puesto que el
Weight (no es transitivo) solo afecta al Router que lo configura.

Local Preference ejemplo:

Recordar que el Local Preference afecta a todo el Sistema autnomo puesto que es un atributo
(transitivo) por ende en R5 configuraremos el local preference para todas las redes que provengan
por Router 7 y lo aumentaremos (esto dara el mismo resultado se en R4 al recibir los prefijos de
R6 le bajaremos el local-preference a un valor menor al por default 100 por ejemplo 99) esto
generara que todos las redes sean preferidas por R7. (2 soluciones posibles para el requerimiento
7) claro utilizando el Local-preference.
Con este atributo realizaremos el punto (7) el cual indica que el ASN64520 debe alcanzar el
ASN64535 por el R7

En este caso con PBR o (Route-map) clasificamos con la expresin regular _64535$ (todo lo que
provenga del ASN 64535)

Le aplicaremos un local preference de 7777777 como es transitivo se propagara a todos los

Routers del ASN por ende la salida preferida ser por R7, incluso R4 que est directamente a R6
preferir darse la vuelta completa para alcanzar los prefijo del ASN64535.

Validaremos ahora en R4 como alcanza las redes del ASN 64535 (show ip bgp)

E
Si lanzamos un Traceroute a cualquiera de esas redes por ejemplo al prefijo 6.6.6.6 desde R4

Ahora un ejemplo con MED y AS-Path en donde lo mismo que en los previos atributos la
diferencia erradica en que MED (no transitivo) y AS-Path (Transitivo)

Ejemplo con Multi-exit-Discriminator (MED): el med tcnicamente viene siendo la mtrica que se
hereda de un protocolo de enrutamiento, por ende a menor MED mucho mejor.

Para esto nos vamos a R5 para indicarle de salida (out) a R7 que para llegar al prefijo 1.1.1.1 en el
ASN 64520 R5 es peor opcin o que no lo escoga y prefiera salir por R4.

Validaremos en R7 como alcanza a 1.1.1.1 de R1

Ahora nos vamos a R5 e indicaremos que cuando este anuncie el prefijo 1.1.1.1 a R7 este posea
una mtrica alta para no ser preferida por R7 y este prefiera a R6 como salida para alcanzar a
1.1.1.1/32

Verificamos en R7 como alcanza a 1.1.1.1/32

 Validamos con un traceroute desde R7 apuntando a 1.1.1.1

Como no es transitivo esto afectara solo como R7 alcanza a 1.1.1.1

Por ende para cumplir el punto 8 tendremos que utilizar el AS-Path que si es un atributo
(Transitivo) a mayor es PEOR.

Y tendremos que aplicarlo en R5 para indicar a R7 que todas las redes del ASN 64520 sean
preferibles por el R6 (anunciaremos un as-path peor).

Tcnicamente el AS-Path es la cantidad de saltos o ASN que los prefijo pasaron anteriormente.

Por lo tanto en R5 haremos lo siguiente para resolver el ltimo punto (8)

Con este ASP_PATH estaremos diciendo que todos los prefijos del ASN64520 cuando el R4 se los
anuncie de salida (out) a R7 este le aadir 3 sistemas autnomos por los cuales pasaron estos
prefijos por ende ser mejor opcin para el ASN64535 salir por R6, puesto que R4 anuncia un solo
ASN en el AS-PATH.