em um servidor executando o Debian Stretch , configurei um bond0 com o modo 802.3ad da seguinte forma:
auto bond0
iface bond0 inet manual
slaves eth0 eth2
bond_miimon 100
bond_mode 802.3ad
A interface bond0 está funcionando, mas está funcionando com o modo de balanceamento de carga (round robin) :
root@servir01:~# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: e4:1f:13:65:f0:c4
Slave queue ID: 0
Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: e4:1f:13:36:a3:ac
Slave queue ID: 0
No switch, o LAG é criado corretamente com o LACP habilitado e tem ambas as portas em funcionamento:
[
A mesma máquina tem outra interface bond (bond1 nas interfaces eth1 e eth3) configurada da mesma forma, conectada nos mesmos switches, e o LACP está funcionando bem:
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: e4:1f:13:65:f0:c6
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 9
Partner Key: 1010
Por que a interface bond0 não deseja habilitar o LACP? Onde estou errado?
Pergunta antiga, mas já que surge bem cedo nas pesquisas, e eu tive uma configuração parecida, com o mesmo problema. Aqui está como eu fiz isso funcionar (usando ifenslave no trecho Debian) ...
/etc/network/interfaces...
Qual foi a causa?
Bem, os NICs apareciam, o driver de bonding os pegava, então os NICs desciam para serem reconfigurados para serem escravos, e o driver de bonding entrava em pânico porque não tinha escravos e corria como uma galinha sem cabeça (round robin ).
Agora, o driver de bonding aparece, vê que não tem escravos, então ele se senta e espera... Os NICs vêem que eles têm um mestre, então eles vão e reportam, pegam seus endereços de bond0 e vão trabalhar todos eles vão.
testado no debian 10 (depois de ler este tópico e a documentação de ligação do debian)
config está abaixo (nenhum outro arquivo editado - módulos ou algo parecido)
o que há de novo:
Passei alguns dias após a atualização do Debian 10 buster (atualização completa) para o Debian 11 Bullseye, então quero compartilhar a solução do problema de ligação.
Após a atualização do Debian Linux, a configuração de tronco existente não está mais funcionando. Há mudanças importantes, conhecidas como bugs:
E anteriormente no Debian 10 a configuração do bond0 era assim:
o que resultou em nenhum bond0 configurado ou até mesmo erros como estes:
ou
mostrando linha de erro
onde 'estrofe' é a chamada configuração do módulo, termo usado pelos desenvolvedores.
A causa raiz disso é que o
ifenslave
pacote foi muito refatorado, a ideia principal era remover a "estrofe" dos itens filhos, que são interfaces físicas (nic), e manter tudo em um só lugar, por exemplo, a própria interface de ligação .Também ainda na
ifenslave
versão 1.22 bug deixou, referindo-se ao comando inexistenteifstate
no Debian 11. A correção fácil e rápida é:Mesmo depois de corrigir isso, o vínculo não funciona, isso significa que há erros de problemas pelos quais o vínculo não está funcionando no Bullseye.
Examinando o código, descobri que a mudança de chave não era apenas remover
bond-mode
do filho e colocá-lo de volta na configuração da interface de vínculo , como era nos primeiros dias do pacote, mas também reverter para o formato inicial dobond-slaves
.Assim, o arquivo de configuração de ligação do Debian 11 Bullseye funciona assim:
Atualização 2022:
Recentemente, em um dos servidores de metal, tive um problema que, após a atualização do kernel e a remoção do kernel antigo, o sistema ficou sem rede. Para encurtar a história - pode haver casos em que o módulo do kernel de ligação não esteja carregado, não esteja presente ou qualquer falha de carregamento devido à mistura de versões ou ao initrd bagunçado. Verifique isso com:
Se não estiver lá, este é um culpado do problema. Tente carregar o módulo manualmente
modprobe bonding
e verifique se ele carrega. Investigue se a versão do kernel carregado corresponde ao que deveria seruname -r
e verifique se o diretório de módulos está presente para essa versão.Referência: https://www.kernel.org/doc/Documentation/networking/bonding.txt
Eu resolvi esse problema adicionando o seguinte à configuração do vínculo em
/etc/network/interfaces
:Depois de adicionar essa configuração e reiniciar a rede, tudo está funcionando bem.