Bonding linux - Como selecionar o endereço MAC usando o modo 2 (balance-xor)

Question

Há alguns dias, escrevi uma pergunta aqui, mas essa pergunta era ambígua. Então, vou tentar reescrever a pergunta, explicando todos os detalhes.

Minha mensagem anterior (mensagem fechada): link

O que você está tentando fazer?

Estou tentando entender como selecionar corretamente o endereço mac, quando uso a ligação, no modo 2 (Equilibre XOR - opção padrão layer2 ).

Estou trabalhando com a ligação do motorista. Estou tentando entender o funcionamento de todos os modos (Modo 0, 1, 2, 3, 4, 5 e 6). Eu entendo como todos os modos funcionam, exceto o modo 2 (balance-xor) e 4 (802.3ad). Porque a opção xmit_hash_policy não está clara!

Minha pergunta principal é: Como posso selecionar um escravo ativo ou outro para enviar tráfego de um ponto para outro par?

Agora, descreverei minha dúvida com todos os detalhes:

No meu laboratório privado, eu tenho 2 computadores (PC1 e PC2, rodando linux / ubuntu) com 4 placas de rede. Em cada computador, eu instalei duas placas de rede (placas de rede).

Endereços Mac em PC1 (bond0):

MAC1(eth1): 62:25:BC:06:4F:A6
MAC2(eth2): 62:25:BC:06:59:E6

Endereços Mac em PC2 (bond0):

MAC4(eth1):62:25:BC:06:5A:1B
MAC3(eth2):62:25:BC:06:59:E9

Então, quando a conexão do driver é carregada, eu posso ver 3 interfaces (bond0, eth1 e eth2) em cada PC (eth1 e eth2 são escravos). Mas, meu problema começa aqui, porque não consigo entender como o kernel seleciona uma interface ou outra.

Às vezes, percebo que todo o tráfego é colocado no mesmo escravo ( por exemplo , do PC1 ao PC2, todo o tráfego será colocado na eth2 do PC2 {MAC = 62:25:BC:06:59:E9} da eth1 do PC1 {MAC = 62:25:BC:06:4F:A6} ). Assim, seguindo o exemplo acima, se eu desabilitar a eth1 no PC2, o tráfego será enviado, mesmo que haja uma interface desabilitada.

Não importa se a interface eth1 no PC2 está ativa ou inativa.

Esse comportamento é esperado. Mas, qual política devo seguir para selecionar o endereço MAC (eth1 ou eth2)? Por que a eth2 no pc2 foi selecionada? E por que a eth1 no pc2 não foi selecionada? O que estou tentando dizer é: como posso saber qual interface eu uso para enviar tráfego do PC1 para o PC2?

Eu tenho uma fórmula que é:

(source MAC XOR destination MAC) modulo slave count

(Esta fórmula foi extraída de bonding.txt - veja a cotação abaixo, no final)

E eu conheço a função hash (gostaria de agradecer ao usuário @Mark Wagner)

/* * Hash for the output device based upon layer 2 data */ static int bond_xmit_hash_policy_l2(struct sk_buff *skb, int count) { struct ethhdr *data = (struct ethhdr *)skb->data;

    if (skb_headlen(skb) >= offsetof(struct ethhdr, h_proto))
            return (data->h_dest[5] ^ data->h_source[5]) % count;

    return 0; }

De acordo com o exemplo acima (envio tráfego de PC1 para PC2 usando eth1 no PC1 e eth2 no PC2). Assim, meus endereços MAC são:

eth1 : 62:25:BC:06:4F:A6  (PC1)
eth2 : 62:25:BC:06:59:E9  (PC2)

Então, como posso determinar qual endereço mac devo usar no PC2? Por que demorou eth2 e não eth1?

O usuário @Mark Wagner tentou me ajudar e escreveu a seguinte explicação:

A função hash real é:

/ *  * Hash para o dispositivo de saída com base nos dados da camada 2  * / estático int bond_xmit_hash_policy_l2 (struct sk_buff * skb, contagem int) {         struct ethhdr * data = (estrutura ethhdr *) skb- > data;

    if (skb_headlen(skb) >= offsetof(struct ethhdr, h_proto))
            return (data->h_dest[5] ^ data->h_source[5]) % count;

    return 0;

}

Onde h_dest e h_source são os endereços MAC. Assumindo os defaults, os endereços MAC de seus títulos são PC1: 62: 25: BC: 06: 4F: A6 e PC2: 62: 25: BC: 06: 5A: 1B. count = 2. Assim, a função hash retorna:

0xA6 ^ 0x5A% 2 = 0

Mas não entendo como calcular a função xor. Alguém pode me explicar como calcular isso?

Obrigado!

**** Apêndice:

Fórmula de bonding.txt

layer2

  Uses XOR of hardware MAC addresses to generate the
  hash.  The formula is

  (source MAC XOR destination MAC) modulo slave count

  This algorithm will place all traffic to a particular
  network peer on the same slave.

  This algorithm is 802.3ad compliant.

Tabela de verdade XOR: link

    

Answer 1

Deixe-me tentar simplificar isso para você. Ao olhar para xmit_hash_policy, pense:

• camada 2 = MAC
• camada 3 = IP
• camada 4 = PORT

Em seguida, pense em "sessão única para cada camada". Exemplo:

• MAC de origem para o destino MAC = Single Session = Single Interface
• IP de origem para o IP de destino = Single Session = Single Interface
• Porta de origem para o destino PORT = Sessão única = Interface única

Coloque de outra forma:

• Único MAC = Interface única usada
• IP único = interface única usada
• Single PORT = Interface Única Usada

Normalmente, quando você se comunica entre dois nós, você tem um único MAC e um único IP. Então você só verá uma única interface sendo usada.

Digamos que você queira aumentar o rendimento entre dois servidores usando 1GbE. Cada servidor é vinculado usando 4 NICs e uma única interface vinculada. Essa interface ligada, digamos bond0, tem um único IP e um único MAC. Nesse cenário, você atingirá no máximo 120MB / s entre os dois servidores.

Em seguida, você adiciona uma subinterface. Esta é basicamente uma interface virtual que lhe dá outro endereço IP. Isso resulta em dois endereços IP na mesma interface vinculada. No linux você teria, por exemplo, bond0 e bond0: 1 dependendo de como você o configurou.

Se você estiver "hashing" na camada 2, vários IPs não geram nada. Você ainda está preso a um único MAC de origem e um único MAC de destino. No entanto, se você hash na camada 3, o driver agora, mais do que provavelmente, equilibrará sua transmissão.

Se você tiver um aplicativo multithread que usa várias portas, digamos portas TCP, convém usar o hash na camada 4, o que equilibrará ainda mais a carga.

Você pode ilustrar isso usando uma ferramenta como o netperf. Em cada cenário, você pode executar o netperf usando vários endereços IP ou várias portas e verá o tráfego equilibrado em várias portas.

Lembre-se, no entanto, isso é apenas transmitir. Receber é controlado pelo comutador. A Cisco permite personalizar a política de hashing. Os interruptores finais mais baixos permitem que você faça as camadas 2 e 3 e a extremidade superior permite que você faça as camadas 2, 3 e 4.

Cenário:

Você tem um servidor de backup e envia dados para um dispositivo de backup NAS. Você usa o modo 4 com xmit_hash_policy = layer3 + 4 no servidor de backup e tem 4 NICs de 1GbE na ligação. Seu software de backup está configurado para enviar dados para o IP do dispositivo de backup, mas faz isso em várias portas TCP com vários fluxos.

Com essa configuração, os dados serão enviados para todas as interfaces, supondo que você tenha fluxos suficientes para serem balanceados. Como isso determina o que vai para onde? Eu acho que você tem a resposta para isso, mas não vou fingir entender como. Eu só sei que isso acontece por experiência.

Então, digamos que agora você tem a capacidade de transmitir dados a 120MB / s * 4 (120MB / s por interface de 1GbE). Mas agora os dados atingem o switch e o switch tem um canal ether (Grupo de Agregação) que é configurado com uma política de hashing na camada 3. (Na Cisco, que pode ser src-ip, dst-ip ou src-dst-ip). Nós vamos com o src-dst-ip para este exemplo. Então agora o switch é o hash baseado nos endereços IP de origem e destino, que são sempre os mesmos, e assim sempre escolherá apenas uma única porta de destino no switch.

Então, enquanto você pode transmitir a 450+ MB / s, o alvo só pode receber 120MB / s.

Se o switch puder usar hash na camada 4 (a Cisco seria src-port, dst-port ou src-dst-port), agora você poderá transferir esses dados do servidor de backup para o appliance usando todas as 4 portas . Isso é presumir que o dispositivo de backup também está ligado.

Mas e se você não tiver um switch Cisco caro e não puder usar hash na camada 4? Você pode criar endereços IP adicionais! Em seguida, você configura seu servidor de backup para executar tarefas usando 4 endereços IP diferentes e ele será balanceado porque o comutador será baseado em hash nos endereços IP de origem e de destino.

Outros fornecedores de chaves possuem seu próprio algoritmo de hash, que geralmente é baseado em uma mistura de IP e MAC (camadas 2 e 3). Eu tive que criar entradas de arp estáticas no passado para tais opções para que houvesse vários endereços IP e vários endereços MAC.

Espero que isso ajude você a entender melhor como o xmit_hash_policy funciona, pelo menos na prática.