¿Es el requisito de 2 n número de puertos para EtherChannel un requisito crítico o simplemente una recomendación para garantizar, tal vez, un equilibrio de carga uniforme?
Particularmente, si configuramos un grupo EtherChannel con 8 puertos pero uno de ellos se cayó. ¿Seguirían siendo funcionales los 7 puertos restantes pero con un equilibrio de carga desigual, o se forzarían a 3 puertos a estar independientes para garantizar una potencia de dos grupos?
¿Se trata de manera similar tanto para PAgP como para LACP?
ieee-802.1ax
etherchannel
Weaam
fuente
fuente
La mayoría de los vendedores no tienen ese requisito. Esta es una convención a menudo discutida en base a las limitaciones de un hash de tres bits al equilibrar la carga. Personalmente no estoy de acuerdo con esta postura, pero llegaré a eso después de responder sus preguntas.
Por lo general, si tiene 8 puertos en un grupo de agregación de enlaces y uno se cae, los otros siete permanecerán activos. Sí, la carga estará un poco desequilibrada en cierto sentido, pero nuevamente, llegaré a eso en un minuto.
Sí, y lo mismo con un grupo LAG estático.
Ahora, desde mi punto de vista, no entiendo personalmente el poder de dos "reglas generales" cuando se trata de la agregación de enlaces.
Para comenzar, realmente necesita comprender que ninguna agregación de enlaces equilibra la utilización de enlaces en todo el LAG . Claramente, hay diferencias en el método de equilibrio de carga elegido, y algunos son mejores que otros (aunque ninguno es el mejor en todas las circunstancias).
El método de equilibrio de carga no equilibra el tráfico, sino que equilibra lo que puede considerar "flujos". Según la plataforma, tiene opciones para usar valores de origen y / o destino que pueden incluir dirección MAC, direcciones IP, números de puerto, etc. Estos valores se combinan para determinar qué enlace se selecciona para ese flujo en particular. Los marcos con el mismo conjunto de valores siempre recibirán el mismo hash y se asignarán al mismo enlace.
No todos los flujos son iguales y esto significa que no es posible equilibrar la utilización del enlace por estos medios. No se debe quitar el valor del LAG, ya que a menudo también hace un buen trabajo al equilibrar la utilización, pero debe comprender las limitaciones.
Es completamente posible que uno o más de estos flujos utilicen su enlace completo en el LAG y eliminen el hambre de otros flujos asignados al mismo enlace. Mientras tanto, los otros enlaces están infrautilizados.
Cuando la mayoría de las personas mira gráficos como los de esta publicación de blog o este documento de Cisco , ven que el tráfico no está equilibrado. En el sentido de que algunos enlaces reciben más flujos que otros, esto es cierto.
Mi opinión sobre estas tablas es un poco diferente. Primero, incluso con la distribución desequilibrada, a medida que agrega enlaces, nunca hay ningún punto en el que aumente el porcentaje de flujos asignados en un enlace; más bien en la mayoría de los casos, el porcentaje disminuye. Dicho de otra manera, en ningún momento hay menos oportunidades para que un flujo tenga acceso al ancho de banda y, en muchos casos, tendrá más oportunidades.
En segundo lugar, si tuviera que mirar este cuadro para decidir entre dos o tres enlaces en un LAG, en mi opinión, vería esto de la siguiente manera:
Finalmente, considere lo que sucede si pierde un enlace en el LAG. Dados dos enlaces para comenzar, esto reduciría mi LAG a un enlace. Si comienzo con tres, todavía me quedarán dos.
Claro, los flujos equilibrados apelan a las partes obsesivas compulsivas de mi personalidad, pero esto todavía no refleja el tráfico equilibrado. Aparte de eso, más enlaces son mejores desde cualquier punto de vista.
fuente
Lo que puedo recordar (corrígeme):
Etherchannel no carga el equilibrio por decir, es la distribución de carga. Un EC con un número impar de enlaces no distribuirá la carga entre los enlaces de manera uniforme: los enlaces de menor número reciben más tráfico. El tráfico continuará fluyendo si los enlaces físicos se rompen.
El tráfico está equilibrado por la dirección mac de destino (por defecto). Dependiendo de su topología, esto puede resultar en patrones de tráfico indeseables:
Si tiene un servidor de correo en un conmutador con un EC entre conmutadores, todas las estaciones de trabajo en el conmutador en el otro lado del Etherchannel utilizarán el mismo enlace para llegar al servidor de correo ... si la mayoría de su tráfico es para el servidor de correo, esto no proporciona equilibrio de carga y solo se utiliza un enlace en el Etherchannel para el servidor de correo.
Esto puede ayudar: https://supportforums.cisco.com/blog/150511/how-do-etherchannel-hash-algorithm-works-and-load-distribution-happen
fuente