Hola, ¿qué tal? Bienvenida o bienvenido a este entrenamiento de Aruba Networking Essentials. Mi nombre es Ricardo Cobos y estoy por comenzar la demostración del laboratorio 6. En esta demostración lo que haré es agregar un enlace redundante de capa 2, éste va a ser un cable que está colocado en las interfaces uno, diagonal uno, diagonal 27 de ambos switches. Al ser un enlace de capa 2 el problema que eso podría traer es la generación de un loop que genera a su vez una tormenta en broadcast, inestabilidad en la tabla MAC y, obviamente, una afectación seria en el rendimiento de la red, así como de los equipos que estén involucrados en esta tormenta de broadcast. Es por eso que hay un protocolo que está habilitado por defecto, en el caso de los switches Aruba o O-S C-X de las serie 6.000, que se llama "spanning tree". Este protocolo lo que hará es detectar estas conexiones redundantes y, a través de la transmisión de mensajes que se llaman "bridge protocol data unit", elegir un dispositivo como el root bridge. Recuerda que este dispositivo se elige utilizando el valor del bridge I-D más bajo entre todos los switches, que se estén comunicando a través de estos B-P-D-U. En este caso, por ejemplo, asumamos que access 1 se vuelve el root bridge. Esto quiere decir que sus puertas serían designated ports que al final del día estarían en modo forwarding. Y el otro dispositivo, que no es el root bridge, debería elegir una interfaz como el root port o la puerta que lo llevaría hacia el root bridge. Y la otra interfaz, la redundante, sería un alternate port que tendría el modo blocking. Eso quiere decir que todos los frames que esta interfaz reciba van a ser descartados. El switch no puede realmente enviar tráfico utilizando la puerta 1 diagonal 1 diagonal 28 y tampoco puede recibir frames en esa interfaz. Vamos a verificar que, efectivamente, si agregamos un enlace redundante, entonces el loop no acontece porque es para instruirlo. Lo que haré para eso es primero verificar cuál es el estado de las interfaces, show interface bridge. En el caso de acceso 2, lo que tengo es la puerta 28 como un enlace troncal, la puerta 27 está configurado como una interfaz de acceso, sin embargo, está deshabilitada y por consecuencia está abajo. Vamos a cambiar esos parámetros. Si yo me voy para la interfaz 1 diagonal 1 diagonal 27, show running current. Esto me va a desplegar la configuración del contexto en el cual yo me encuentro y veo que la configuración dice "shutdown, no routing, VLAN Access 1 exit". Primero lo voy a habilitar "no shut" y si ahora valido, "show interface break", ya podemos ver que la interfaz se encuentra arriba de este lado, sigue siendo una interfaz de acceso pero el estatus es down, eso es porque estamos esperando por el enlace a que se levante y no levantará hasta que yo lo configure de la misma manera en acceso 1. El último cambio que me gustaría hacer aquí es prepararlo para que transporte las mismas VLANs que está permitiendo el puerto 28. Haré VLAN trunk allow 1, 20, 99 y ahora sí vuelvo a repetir el mismo comando show interface break, sin embargo, ahora lo filtraré y solamente incluirle "Include 1 diagonal 1 diagonal 27" veré que ahora ya es una interfaz en modo troncal. Lo que seguiría sería movernos a acceso 1 y configurar el enlace 1 diagonal uno, diagonal 27 o la puerta 27 para ese enlace como una puerta troncal que se encuentra habilitada, no shut y después VLAN trunk allow 1, 20, 99. Si veo las interfaces veo que, efectivamente, ahora las dos interfaces se encuentran arriba y en el caso de la puerta 27 es una puerta troncal. Lo que sigue ahora sería ver el estado de show spanning tree, y veo que efectivamente, spanning tree está habilitado. El modo es M-S-T-P, ese es el modo por defecto y, entre tantas cosas, lo que puedo ver es que el bridge I-D local es combinado con esta dirección MAC 74 E 8 81 3 F B 5 C 0. Pero el bridge I-D del root bridge es diferente. Este es 32 7 68 64 E 8 81 3 F 16 80. Esto quiere decir que acceso 1 no es el root bridge. Y eso lo podemos confirmar si vemos el estado de las interfaces. La puerta 27 es la puerta root y la puerta 28 es alternate en modo blocking. En otras palabras, acceso 2 es el root bridge, en este caso. Si yo me voy para ese switch y repito el mismo comando "show spanning tree" veo que efectivamente, el bridge I-D de este dispositivo, es igual al bridge I-D del root bridge. En otras palabras, acceso 2 es el root bridge. Lo cual, efectivamente, me está cambiando los roles en el diagrama que yo tengo aquí. Voy a mover root bridge para acceso 2 y, obviamente, el estado de las interfaces también cambia su rol y su estado. En otras palabras, realmente el que está bloqueando el tráfico es Acceso 1. Yo podría cambiar estos roles modificando el bridge I-D, específicamente, el bridge priority, acceso 1 lo podría reducir y así volver acceso 1 el root bridge, porque él tendría el bridge I-D más bajo. Sin embargo, esto está más allá del alcance de este entrenamiento, pero es importante que sepas que esto se puede hacer. Ahora, lo que nosotros estamos teniendo aquí es simplemente redundancias, se están evitando los loops y tenemos redundancia. ¿Cómo sé que tenemos redundancia? Si, por ejemplo, yo llegara a tener una falla en el enlace 27, aquel enlace que está realmente activo. Si nosotros tuviéramos una una falla aquí, este puerto ya no estaría bloqueado, se volvería el root port y estaría en modo forwarding. Eso quiere decir que, ante la falla del enlace de abajo, ahora el tráfico que utilizaba ese enlace no lo usará más, porque el enlace obviamente se habrá caído y ahora utilizará el enlace que se encuentra arriba. Vamos a intentarlo. Lo que voy a hacer en ese caso es primero moverme para PC 4 y estar generando tráfico entre PC 4 y PC 1. Aquí en PC 4 estar enviando un ping continuo para PC1 y, obviamente, el resultado es que tengo respuestas. Si me muevo para para el acceso 1, específicamente, la interfaz 1 1 27, que es el root port, y lo deshabilito, veré cómo las interfaces cambian de rol y, obviamente, de estado. El puerto 28 es el root port y se encuentra en modo forwarding, tal y como lo habíamos previsto. Si voy para PC 4 veo que, obviamente, el ping, de hecho lo voy a detener y voy a comenzar uno nuevo, el ping continúa sin problema alguno, no se perdió la conectividad. Esto es porque gracias a la redundancia que yo tengo y un automatic failover, que me ofrece spanning tree ante la caída del enlace en la puerta 27, enlace de la puerta 28, se reactiva.
