Pero para ello tenemos que cumplir ciertas normas. Para poder usar esta tecnología tendremos que cumplir con los siguientes requisitos.

Transcripción

1 Uno de los mayores problemas que tenemos a la hora de ofrecer rendimiento cuando tenemos muchísimos equipos de acceso son los cuellos de botella que se pueden crear hacia los equipos de distribución. Aunque los switchs están diseñados para soportar una sobresuscripción notable, incluso muchos disponen de algunos pocos puertos de mayor velocidad, no estaría de más poder tener mayor ancho de banda y de paso nos aseguramos un poco de redundancia a nivel de enlaces. Pero aquí tenemos un problema, como en toda red L2, Spanning tree debe de estar funcionando para evitar sustos, y al detectar más de un cable hacia el mismo equipo, detecta un bucle y te los bloquea todos excepto uno, dejando nuestra intención de tener más ancho de banda para la subida en nada, pero bueno, al menos sabemos que si se cae el enlace activo, STP nos desbloqueará uno, por lo que al menos hemos ganado en redundancia. Pero esto no nos consuela, como vamos a conseguir ese mayor ancho de banda si STP se dedicará a bloquearnos todos los intentos? Fácil, vamos a engañarle Vamos con un poco de historia, a principios de los 90 surgió una tecnología que se llamaba Etherchannel que nos permitía hacer enlaces de agregación, es decir, juntar varios enlaces como si fuese uno con la suma de todas las velocidades y mostrarse como tal, en vez de como varios puertos. Esto hacia ver a STP que en vez de tener dos cables de 100 físicos, tiene uno lógico de 200, y al solo ver uno, no tenía motivos para bloquearlo, a no ser que existiese un bucle por otro lado claro! Además, como este enlace se mostraba como uno de mayor velocidad, su coste para los protocolos era siempre más bajo, así que tenía menor coste. Años más tarde, esta tecnología fue comprada por Cisco, quien se patentó un protocolo de negociación llamado PAGP (Port Aggregation Protocol) y a principios de siglo se estandarizó como 802.3ad y un protocolo de negociación similar, llamado LACP. De esta forma conseguimos nuestro objetivo, tenemos más ancho de banda, tenemos redundancia (el Port-channel, que es el nombre del nuevo puerto lógico, seguirá arriba siempre que tenga al menos un link físico arriba, por lo que si cae uno, STP no se entera) y además me dará balanceo de carga, porque el propio protocolo se encarga de repartir los paquetes por los diferentes enlaces físicos. Pero para ello tenemos que cumplir ciertas normas. Para poder usar esta tecnología tendremos que cumplir con los siguientes requisitos.

2 - Los miembros del PortChannel tienen que tener la misma velocidad, tipo y config - Todos los miembros del Portchannel tienen que conectar contra el mismo equipo (o al menos que parezca ;-) ) - Ambos extremos deben de tener una configuración idéntica (protocolo de negociación, config de puertos, etc) - Un puerto físico no puede ser miembro de varios PortChannels - Máximo grupos de 16 puertos (aunque solo habrá 8 activos) Lo mejor es configurarlo cuando aún no hay nada puesto en los equipos físicos, y luego configuramos la interfaz PortChannel como si fuese un puerto más, su config se reflejará en los puertos físicos que lo componen, pero id con cuidado! Si configuráis algo en un puerto físico de forma individual, esto puede no reflejarse en el PortChannel, creando inconsistencias. La configuración es sencilla, basta con entrar a las interfaces que formaran el nuevo PortChannel y poner el comando channel-group # mode modo, donde # será el identificador del nuevo Portchannel y el modo puede ser activo, pasivo, auto, desirable u on. Pero qué significa cada modo? Si elegimos activo o pasivo, estamos usando LACP, si elegimos auto o desirable, usamos PAGP y si le decimos simplemente on, no usamos negociación, vamos directos. Como todo cable, este tendrá dos extremos, por lo que tanto configuraremos Etherchannel en los dos extremos respetando la siguiente tabla, donde Yes indica que combinaciones aceptarían levantar un PortChannel Como vemos en esta configuración, cogemos el puerto Ethernet1/1 y 1/2 y lo ponemos en active (LACP), tendríamos que poner la misma línea en Switch2, ya sea como active o como passive. Recordad que no podemos mezclar protocolos y el on solo funciona con on Como podemos ver nos crea una interfaz llamada Port-Channel 1, la cual configuramos como una interfaz más Para verificar el estado de los portchannels, puedo utilizar el comando show etherchannel summary

3 Aquí vemos que tengo un solo portchannel con el identificador del grupo 1, este se encuentra SU, la S es que es de L2, si el equipo soportase podría hacerlos también de L3 y saldría una R, y la U quiere decir In Use, es decir, que funciona. Podemos ver que en protocolo aparece LACP, porque hemos configurado con el modo active y en Ports aparecen los puertos miembros, que se encuentran en P, que quiere decir que están en el Port-channel correctamente. Con esto ya nos podríamos ir a casa pero como somos curiosos, vamos a ver qué criterios usa a la hora de balancear el tráfico por los dos enlaces. Por defecto, lo que hace es asignar un índice a cada miembro, empezando por el 0, en este caso, como tenemos dos puertos, así que Eth1/1 será el 0 y Eth1/2 será el 1, luego, por cada flujo de tráfico, coge la IP origen y la IP destino y les aplica una XOR, como solo tenemos dos miembros, solo mira el último bit, y si es cero se va por Eth1/1 y si es 1 se va por Eth1/2, si tuviésemos 4 miembros, cogería dos bits porque numeraria del 0 al 3. Es recomendable tener miembros potencia de dos porque si tuviésemos 3, si saliese la combinación que haría referencia al miembro que falta, se iría por el primer puerto, por lo que estaría mas cargado. Pues bien, por defecto se basa en la IP origen y la IP destino, les haría la XOR y con el resultado

4 elegiría el enlace por el cual salir Pero puedo cambiar de criterio según mi necesidad con port-channel load-balance CRITERIO Eso sí, será el mismo para todos los port-channels del equipo Y eso es todo, con esto conseguimos redundancia a nivel de link entre dos dispositivos, pero y si se cae el equipo de distribución? No hay problema, nada nos impide tener otro portchannel con otros puertos y conectar a otro equipo, a ojos de STP será como un link más. Fijaros que, en este dibujo, bucle entre dos equipos no existe pero si de forma global, i STP nos bloquearía

5 uno de los portchannels Pero hay entornos donde no nos podemos permitir tener un enlace bloqueado, como puede ser un CPD. Ciertos equipos tienen la capacidad de engañar a Etherchannel ( y por lo tanto a STP) y hacer ver que dos equipos o más físicos son uno, lo que nos permitiría bifurcar el portchannel por si se cayese uno de los físicos, para ello tenemos tres tecnologías En los 6500,6800 y 4500-X, tenemos VSS, donde ponemos un par de equipos en clúster y se muestran como uno solo En muchos multicapa como el 3850-X tenemos la solución Stackwise, que interconecta varios Catalyst 3850-X con un cable especial y los muestra como un solo equipo (un único control plane, igual que el VSS)

6 Y por último, la familia Nexus de Cisco tiene puede hacer lo que se conoce como vpc, donde dos equipos se ponen de acuerdo para mostrarse como uno solo, aunque internamente cada uno sigue teniendo su plano de control y de datos por separado Y hasta aquí todo lo referente a la agregación de enlaces, una solución magnifica para mejorar el rendimiento y ganar en redundancia, tanto de enlace como en estos últimos ejemplos, de equipo.