EtherChannel y número impar de puertos


9

¿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?

Respuestas:


8

El poder de 2 requisitos varía según el proveedor / hardware / software. Cisco tenía (tiene) un estigma bastante malo contra ellos con muchos de los conmutadores de catalizador anteriores capaces de 10G. El problema viene con la forma en que el software procesa (o "equilibra") los datos en los múltiples puertos en el canal del puerto (esto es independiente de PAgP o LACP).

Esta publicación hace un excelente trabajo simplificando el problema con mayor detalle. Esto es menos relevante hoy en día con las mejoras de hardware / software, pero nuevamente, varía, así que solo verifique los requisitos de hardware y asegúrese de no comprar hardware antiguo que sea víctima de este problema.

http://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/


2
Los documentos de origen serían: cisco.com/c/en/us/support/docs/lan-switching/etherchannel/… con las mejoras enumeradas en este documento: cisco.com/c/en/us/products/collateral/switches/…
cpt_fink

3

¿Es el requisito de 2n número de puertos para EtherChannel un requisito crítico o simplemente una recomendación para garantizar, tal vez, un equilibrio de carga uniforme?

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.

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?

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.

¿Se trata de manera similar tanto para PAgP como para LACP?

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:

  • Dos enlaces : un solo enlace que se utilice por completo afectará al 50% de los flujos de tráfico y no afectará el 50%
  • Tres enlaces : un solo enlace que se utilice por completo afectará a lo sumo el 37.5% de los flujos de tráfico, dejando al 62.5% sin afectar; posiblemente tan poco como el 25% dejando al 75% no afectado

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.


Generalmente estoy de acuerdo con la lógica "más puertos = mejor". Una cosa a tener en cuenta es que la resolución de problemas intermitentes (latencia o paquetes descartados) causados ​​por un solo miembro de canal maximizado puede ser doloroso, por lo que es importante monitorear enlaces individuales y recordar mirarlos durante la resolución de problemas.
cpt_fink

1
Convenido. Sin embargo, eso es cierto si uno sigue el poder de dos reglas o no. Si tengo la opción, siempre grafo valores para las interfaces LAG y las interfaces individuales.
YLearn

2

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.