Como exatamente e especificamente o hash de endereço de destino do LACP da camada 3 funciona?

Com base em uma pergunta anterior há mais de um ano ( Ethernet multiplexada de 1 Gbps? ), Parti e configurei um novo rack com um novo ISP com links LACP em todo o lugar. Precisamos disso porque temos servidores individuais (um aplicativo, um IP) que atendem milhares de computadores clientes em toda a Internet além de 1 Gbps cumulativo.

Supõe-se que essa idéia do LACP nos permita romper a barreira de 1 Gbps sem gastar uma fortuna em switches e placas de rede 10GoE. Infelizmente, eu tive alguns problemas com a distribuição de tráfego de saída. (Isso apesar do aviso de Kevin Kuphal na questão vinculada acima).

O roteador do ISP é um Cisco de algum tipo. (Deduzi isso do endereço MAC.) Meu switch é um HP ProCurve 2510G-24. E os servidores são HP DL 380 G5s executando o Debian Lenny. Um servidor está em espera quente. Nosso aplicativo não pode ser agrupado. Aqui está um diagrama de rede simplificado que inclui todos os nós de rede relevantes com IPs, MACs e interfaces.

Embora tenha todos os detalhes, é um pouco difícil trabalhar e descrever o meu problema. Portanto, por uma questão de simplicidade, aqui está um diagrama de rede reduzido aos nós e links físicos.

Então, saí e instalei meu kit no novo rack e conectei os cabos do meu ISP a partir do roteador. Ambos os servidores têm um link LACP para o meu switch, e o switch possui um link LACP para o roteador ISP. Desde o início, percebi que minha configuração do LACP não estava correta: os testes mostravam todo o tráfego de e para cada servidor passando por um link GoE físico exclusivamente entre o servidor para o switch e o switch para o roteador.

Com algumas pesquisas no Google e muito tempo RTMF em relação à ligação NIC do linux, descobri que podia controlar a ligação da NIC modificando /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

Isso fez com que o tráfego saísse do meu servidor pelas duas placas de rede, conforme o esperado. Mas o tráfego estava passando do switch para o roteador por apenas um link físico, ainda .

Precisamos desse tráfego passando pelos dois links físicos. Após ler e reler o Guia de Configuração e Gerenciamento do 2510G-24 , eu encontro:

[LACP usa] pares de endereços de origem e destino (SA / DA) para distribuir o tráfego de saída através de links troncalizados. O SA / DA (endereço de origem / endereço de destino) faz com que o comutador distribua o tráfego de saída para os links dentro do grupo de troncos com base nos pares de endereços de origem / destino. Ou seja, o switch envia tráfego do mesmo endereço de origem para o mesmo endereço de destino através do mesmo link troncalizado e envia tráfego do mesmo endereço de origem para um endereço de destino diferente através de um link diferente, dependendo da rotação das atribuições de caminho entre os links no tronco.

Parece que um link vinculado apresenta apenas um endereço MAC e, portanto, o caminho do servidor para o roteador sempre estará sobre um caminho do switch para o roteador porque o switch vê apenas um MAC (e não dois - um de cada porta) para os dois links do LACP.

Entendi. Mas é isso que eu quero:

Um switch HP ProCurve mais caro é o 2910al usa endereços de origem e destino de nível 3 em seu hash. Na seção "Distribuição de tráfego de saída através de links troncalizados" do Guia de gerenciamento e configuração do ProCurve 2910al :

A distribuição real do tráfego através de um tronco depende de um cálculo usando bits do endereço de origem e endereço de destino. Quando um endereço IP está disponível, o cálculo inclui os últimos cinco bits do endereço de origem e endereço de destino IP, caso contrário, os endereços MAC são usados.

ESTÁ BEM. Portanto, para que isso funcione da maneira que eu quero, o endereço de destino é a chave, pois meu endereço de origem é fixo. Isso leva à minha pergunta:

Como exatamente e especificamente o hash LACP da camada 3 funciona?

Preciso saber qual endereço de destino é usado:

• o IP do cliente , o destino final?
• Ou o IP do roteador , o próximo destino de transmissão do link físico.

Ainda não saímos e compramos um interruptor de substituição. Por favor, ajude-me a entender exatamente se o hash do endereço de destino da camada 3 do LACP é ou não o que eu preciso. Comprar outra opção inútil não é uma opção.

O que você procura geralmente é chamado de "política de hash de transmissão" ou "algoritmo de transmissão de hash". Controla a seleção de uma porta de um grupo de portas agregadas com as quais transmitir um quadro.

É difícil colocar as mãos no padrão 802.3ad porque não estou disposto a gastar dinheiro com isso. Dito isto, pude recolher algumas informações de uma fonte semioficial que lança alguma luz sobre o que você está procurando. De acordo com esta apresentação do grupo de estudo de alta velocidade ITAE de Ottawa, ON, CA de 2007, que atende ao padrão 802.3ad, não exige algoritmos específicos para o "distribuidor de quadros":

Este padrão não exige nenhum algoritmo de distribuição específico; no entanto, qualquer algoritmo de distribuição deve garantir que, quando os quadros forem recebidos por um Frame Collector, conforme especificado em 43.2.3, o algoritmo não cause: a) Ordenação incorreta dos quadros que fazem parte de uma conversa ou b) Duplicação de quadros . O requisito acima para manter a ordem dos quadros é atendido, garantindo que todos os quadros que compõem uma determinada conversa sejam transmitidos em um único link na ordem em que são gerados pelo cliente MAC; portanto, esse requisito não envolve a adição (ou modificação) de nenhuma informação ao quadro MAC, nem buffer ou processamento por parte do Frame Collector correspondente para reordenar os quadros.

Portanto, qualquer algoritmo que um driver de switch / NIC use para distribuir quadros transmitidos deve seguir os requisitos conforme declarado naquela apresentação (que, presumivelmente, estava citando o padrão). Não há um algoritmo específico especificado, apenas um comportamento compatível definido.

Mesmo que não haja um algoritmo especificado, podemos analisar uma implementação específica para ter uma ideia de como esse algoritmo pode funcionar. O driver de "ligação" do kernel Linux, por exemplo, possui uma política de transmissão de hash compatível com 802.3ad que aplica a função (consulte bonding.txt no diretório Documentation \ networking da fonte do kernel):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Isso faz com que os endereços IP de origem e de destino, bem como os endereços MAC de origem e destino, influenciem a seleção da porta.

O endereço IP de destino usado nesse tipo de hash seria o endereço presente no quadro. Tome um segundo para pensar sobre isso. O endereço IP do roteador, em um cabeçalho de quadro Ethernet distante do servidor para a Internet, não está encapsulado em nenhum lugar desse quadro. O endereço MAC do roteador está presente no cabeçalho de um quadro, mas o endereço IP do roteador não está. O endereço IP de destino encapsulado na carga útil do quadro será o endereço do cliente da Internet que fez a solicitação ao seu servidor.

Uma política de hash de transmissão que leve em consideração os endereços IP de origem e de destino, supondo que você tenha um conjunto variado de clientes, deve fazer muito bem por você. Em geral, endereços IP de origem e / ou de destino mais variados no tráfego que flui através de uma infraestrutura agregada resultarão em agregação mais eficiente quando uma política de hash de transmissão baseada na camada 3 for usada.

Seus diagramas mostram solicitações que chegam diretamente aos servidores da Internet, mas vale ressaltar o que um proxy pode fazer com a situação. Se você estiver executando proxy de solicitações de clientes para seus servidores, como chris fala em sua resposta , poderá causar gargalos. Se esse proxy estiver fazendo a solicitação com seu próprio endereço IP de origem, em vez do endereço IP do cliente da Internet, você terá menos "fluxos" possíveis em uma política de hash de transmissão estritamente baseada em camada 3.

Uma política de hash de transmissão também pode levar em consideração as informações da camada 4 (números de porta TCP / UDP), desde que cumpridas com os requisitos do padrão 802.3ad. Esse algoritmo está no kernel do Linux, como você faz referência na sua pergunta. Lembre-se de que a documentação desse algoritmo adverte que, devido à fragmentação, o tráfego pode não necessariamente fluir no mesmo caminho e, como tal, o algoritmo não é estritamente compatível com 802.3ad.

surpreendentemente, alguns dias atrás, nossos testes mostraram que xmit_hash_policy = layer3 + 4 não terá efeito entre dois servidores linux conectados diretamente, todo o tráfego usará uma porta. ambos executam o xen com 1 ponte que possui o dispositivo de ligação como membro. Obviamente, a ponte pode causar o problema, apenas que não faz sentido, considerando que seria usado o hash baseado em porta IP +.

Eu sei que algumas pessoas realmente conseguem enviar mais de 180 MB por links vinculados (ou seja, usuários do ceph), então isso funciona em geral. Possíveis coisas a serem observadas: - Usamos o antigo CentOS 5.4 - O exemplo dos OPs significaria que o segundo LACP "unhashes" as conexões - isso faz algum sentido?

O que esta discussão e documentação lendo etc etc me mostrou:

• Geralmente, todo mundo sabe muito sobre isso, é bom em recitar a teoria do howto de ligação ou mesmo dos padrões IEEE, enquanto a experiência prática é quase nula.
• A documentação do RHEL está incompleta, na melhor das hipóteses.
• A documentação de ligação é de 2001 e não é atual o suficiente
• aparentemente, o modo layer2 + 3 não está no CentOS (não aparece no modinfo e, em nosso teste, diminuiu todo o tráfego quando ativado)
• Não ajuda que SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) e RedHat (BONDING_OPTS) tenham maneiras diferentes de especificar as configurações do modo por ligação
• O módulo do kernel do CentOS / RHEL5 é "seguro para SMP", mas não "compatível com SMP" (consulte a palestra de alto desempenho do facebook) - NÃO é escalável acima de uma CPU, portanto, com o aumento do clock da CPU> muitos núcleos

Se alguém terminar uma boa configuração de ligação de alto desempenho, ou realmente souber do que está falando, seria incrível se eles levassem meia hora para escrever um novo pequeno tutorial sobre como documentar UM exemplo de trabalho usando LACP, sem coisas estranhas e largura de banda > um link

Se o seu switch vê o verdadeiro destino L3, ele pode fazer hash nele. Basicamente, se você tiver 2 links, pense que o link 1 é para destinos numerados ímpares, o link 2 é para destinos numerados pares. Acho que eles nunca usam o IP do próximo salto, a menos que estejam configurados para fazê-lo, mas é praticamente o mesmo que usar o endereço MAC do destino.

O problema que você encontrará é que, dependendo do seu tráfego, o destino sempre será o endereço IP único do servidor, para que você nunca use esse outro link. Se o destino for o sistema remoto na Internet, você obterá uma distribuição uniforme, mas se for algo como um servidor Web, em que seu sistema é o endereço de destino, o comutador sempre enviará tráfego por apenas um dos links disponíveis.

Você ficará ainda pior se houver um balanceador de carga em algum lugar, pois o IP "remoto" sempre será o IP do balanceador de carga ou o servidor. Você pode contornar isso um pouco usando muitos endereços IP no balanceador de carga e no servidor, mas isso é um hack.

Você pode expandir um pouco o seu horizonte de fornecedores. Outros fornecedores, como redes extremas, podem fazer hash em coisas como:

Algoritmo L3_L4 - Camada 3 e Camada 4, os endereços IP de origem e destino combinados e os números de porta TCP e UDP de origem e destino. Disponível nos comutadores das séries SummitStack e Summit X250e, X450a, X450e e X650.

Então, basicamente, enquanto a porta de origem do cliente (que geralmente muda muito) mudar, você distribuirá o tráfego uniformemente. Tenho certeza de que outros fornecedores possuem recursos semelhantes.

Mesmo o hash no IP de origem e destino seria suficiente para evitar pontos de acesso, desde que você não tenha um balanceador de carga no mix.

Acho que está fora do IP do cliente, não do roteador. Os IPs reais de origem e destino estarão em um deslocamento fixo no pacote, e isso será rápido para fazer hash. Hashing do IP do roteador exigiria uma pesquisa baseada no MAC, certo?

Desde que acabei de voltar aqui, algumas coisas que aprendi até agora: para evitar cabelos grisalhos, você precisa de uma opção decente que suporte uma política de camada 3 + 4, e a mesma também no Linux.

Em alguns casos, o maçarico pervertido de padrões chamado ALB / SLB (modo6) pode funcionar melhor. Operacionalmente, é uma porcaria.

Eu mesmo tento usar 3 + 4 sempre que possível, pois muitas vezes quero essa largura de banda entre dois sistemas adjacentes.

Eu também tentei com o OpenVSwitch e já tive uma instância em que esse tráfego interrompido flui (todos os primeiros pacotes perdidos ... não faço ideia)