O requisito de 2 n número de portas para o EtherChannel é um requisito crítico ou apenas uma recomendação para garantir, talvez, um equilíbrio de carga uniforme?
Particularmente, se configurarmos um grupo EtherChannel com 8 portas, mas uma delas caiu. As 7 portas restantes ainda funcionariam, mas com um equilíbrio de carga desigual, ou 3 portas seriam forçadas a ficarem independentes para garantir a força de dois grupos?
É tratado da mesma forma para o PAgP e o LACP?
Respostas:
O requisito de potência 2 varia de acordo com o fornecedor / hardware / software. A Cisco tinha (tem) um estigma bastante ruim contra eles com muitos dos switches catalisadores anteriores capazes de 10G. O problema ocorre com a maneira como o software faz o hash (ou "equilibra") os dados nas várias portas do canal de porta (isso é independente do PAgP ou LACP).
Este post faz um excelente trabalho ao simplificar o problema com mais detalhes. Hoje, isso é menos relevante com as melhorias de hardware / software, mas, novamente, varia - basta verificar os requisitos de hardware e garantir que você não esteja comprando hardware mais antigo que é vítima desse problema.
http://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/
O requisito do número 2n de portas para o EtherChannel é um requisito crítico ou apenas uma recomendação para garantir, talvez, um equilíbrio de carga uniforme?
A maioria dos fornecedores não tem esse requisito. Essa é uma convenção frequentemente discutida com base nas limitações de um hash de três bits no balanceamento de carga. Pessoalmente, não concordo com essa postura, mas chegarei a isso depois de responder às suas perguntas.
Particularmente, se configurarmos um grupo EtherChannel com 8 portas, mas uma delas caiu. As 7 portas restantes ainda funcionariam, mas com um equilíbrio de carga desigual, ou 3 portas seriam forçadas a ficarem independentes para garantir a força de dois grupos?
Normalmente, se você tiver 8 portas em um grupo de agregação de links e uma for desativada, as outras sete permanecerão ativas. Sim, a carga será um pouco desequilibrada em certo sentido, mas novamente, chegarei a isso em um minuto.
É tratado da mesma forma para o PAgP e o LACP?
Sim, e o mesmo com um grupo LAG estático.
Agora, do meu ponto de vista, por que eu não mantenho pessoalmente o poder de duas "regras básicas" quando se trata de agregação de links.
Para começar, você realmente precisa entender que nenhuma agregação de links equilibra a utilização de links no LAG . Claramente, existem diferenças no método de balanceamento de carga escolhido, e alguns são melhores que outros (embora ninguém seja o melhor em todas as circunstâncias).
O método de balanceamento de carga não equilibra o tráfego, mas sim o que você pode considerar "fluxos". Com base na plataforma, você tem opções para usar valores de origem e / ou destino, que podem incluir endereço MAC, endereços IP, números de porta etc. Esses valores são divididos em hash para determinar qual link será selecionado para esse fluxo específico. Os quadros com o mesmo conjunto de valores sempre receberão o mesmo hash e serão atribuídos ao mesmo link.
Nem todos os fluxos são iguais e isso significa que não é possível equilibrar a utilização do link por esses meios. Para não tirar o valor do LAG, pois muitas vezes ele faz um bom trabalho ao equilibrar a utilização, mas você precisa entender as limitações.
É inteiramente possível que um ou mais desses fluxos utilizem todo o link no GAL e deixem passar outros fluxos atribuídos ao mesmo link. Enquanto isso, os outros links estão subutilizados.
Quando a maioria das pessoas olha para gráficos como os desta publicação do blog ou deste documento da Cisco , vê que o tráfego está desequilibrado. No sentido de que alguns links recebem mais fluxos que outros, isso é verdade.
Minha visão dessas tabelas é um pouco diferente. Primeiro, mesmo com a distribuição desequilibrada, à medida que você adiciona links, nunca há um ponto em que a porcentagem de fluxos atribuídos em um link aumenta; na maioria dos casos, a porcentagem diminui. Em outras palavras, em nenhum momento há menos oportunidade para um fluxo ter acesso à largura de banda e, em muitos casos, ele terá mais oportunidades.
Segundo, se eu olhar para este gráfico para decidir entre dois ou três links em um GAL, na minha mente, vejo o seguinte:
Por fim, considere o que acontece se você perder um link no GAL. Dados dois links para iniciar, isso reduziria meu GAL a um link. Se eu começar com três, ainda terei mais dois.
Certamente, fluxos equilibrados atraem as partes obsessivas e compulsivas da minha personalidade, mas isso ainda não reflete o tráfego equilibrado. Além disso, mais links são melhores de qualquer maneira que eu veja.
O que me lembro (me corrija):
O Etherchannel não carrega o equilíbrio por dizer, é a distribuição de carga. Um EC com um número ímpar de links não distribuirá a carga entre os links uniformemente - os links com menor número recebem mais tráfego. O tráfego continuará fluindo se os links físicos estiverem quebrados.
O tráfego é balanceado pelo endereço MAC de destino (por padrão). Dependendo da sua topologia, isso pode resultar em padrões de tráfego indesejáveis:
Se você tiver um servidor de correio em um comutador com um EC entre comutadores, todas as estações de trabalho no comutador do outro lado do Etherchannel usarão o mesmo link para acessar o servidor de email .... se a maior parte do seu tráfego for servidor de correio, isso não fornece balanceamento de carga e apenas um único link no Etherchannel é usado para o servidor de correio.
Isso pode ajudar: https://supportforums.cisco.com/blog/150511/how-do-etherchannel-hash-algorithm-works-and-load-distribution-happen