Bonding de Rede Explicado: Todos os 7 Modos, Arquitetura e Configuração no Mundo Real

Network bonding — também chamado de NIC teaming, agregação de links ou Ethernet bonding — é a técnica de combinar duas ou mais placas de interface de rede (NICs) físicas numa única interface lógica gerida pelo kernel do sistema operativo. O resultado é um dispositivo de rede unificado que oferece maior largura de banda agregada, failover automático e distribuição de carga em todos os links membros simultaneamente.

Ao nível do kernel em sistemas Linux, o bonding é implementado através do módulo de kernel `bonding`, que apresenta uma única interface virtual (normalmente denominada `bond0`) à pilha de rede. Esta abstração significa que as aplicações, tabelas de roteamento e regras de firewall interagem com uma interface independentemente de quantas NICs físicas existem por baixo — um detalhe arquitetónico crítico que simplifica a gestão enquanto oferece resiliência de nível empresarial.

Por Que o Network Bonding É Importante em Ambientes de Produção

Antes de mergulhar nos modos, vale a pena compreender precisamente que problema o bonding resolve — e onde não resolve. Uma única porta Gigabit Ethernet tem um limite máximo de aproximadamente 125 MB/s de throughput. Para um servidor de base de dados, um nó de armazenamento ou uma aplicação web de alto tráfego, esse limite é atingido rapidamente. O bonding de duas NICs 1 GbE não duplica magicamente o throughput para um único fluxo TCP (isso é um equívoco comum), mas permite que múltiplos fluxos simultâneos saturem ambos os links, duplicando efetivamente a capacidade agregada.

Além do throughput bruto, o bonding elimina o ponto único de falha que uma NIC ou cabo isolado representa. Em ambientes onde o tempo de atividade é medido em noves, isso é enormemente importante.

Principais Benefícios em Resumo

• Largura de banda agregada: Múltiplos links físicos contribuem para o throughput total para fluxos de tráfego simultâneos
• Failover automático: A deteção de falha de link (via monitorização MII ou ARP) desencadeia uma comutação em menos de um segundo para uma interface sobrevivente
• Distribuição de carga: O tráfego é distribuído pelas interfaces membro de acordo com o algoritmo de bonding ativo
• Transparente para as aplicações: A interface bond tem um único endereço MAC e IP, não requerendo alterações ao nível da aplicação
• Eficiência de custo de hardware: O bonding de NICs de uso geral pode ser mais económico do que atualizar para uma única placa 10 GbE em alguns cenários

Arquitetura do Network Bonding: Como Funciona Internamente

O driver de bonding do kernel Linux opera entre a Camada 2 (Ligação de Dados) e os drivers físicos de NIC. Quando uma frame é transmitida, a política de transmissão do driver de bonding seleciona qual interface slave utilizar. Na receção, todas as interfaces slave passam as frames para o bond master, que as deduplica e entrega à pilha de rede.

A monitorização de links é o mecanismo que deteta falhas. Existem dois métodos:

• Monitorização MII (Media Independent Interface): Verifica o estado do link físico de cada NIC num intervalo configurável (parâmetro `miimon`, tipicamente 100ms). Rápido e fiável para detetar desconexões de cabos ou falhas de NIC.
• Monitorização ARP: Envia pedidos ARP para um IP alvo e aguarda respostas. Mais útil quando é necessário verificar a conectividade de ponta a ponta em vez de apenas o estado do link físico, mas introduz dependência de um alvo ARP acessível.

Os parâmetros `downdelay` e `updelay` adicionam histerese — prevenindo oscilações rápidas quando um link flutua. Definir estes para 200ms cada é uma linha de base comum em produção.

Todos os 7 Modos de Bonding Linux: Análise Técnica Aprofundada

O driver de bonding Linux define sete modos distintos (0 a 6). Cada um implementa uma política de transmissão e comportamento de failover diferentes. Selecionar o modo errado é uma das configurações incorretas mais comuns em implementações de servidores.

Modo 0 — Round-Robin (balance-rr)

Os pacotes são transmitidos sequencialmente por todas as interfaces slave ativas de forma rotativa: pacote 1 em eth0, pacote 2 em eth1, pacote 3 em eth0, e assim por diante.

O que realmente acontece: O round-robin opera ao nível do pacote, não ao nível do fluxo. Isto significa que uma única conexão TCP pode ter os seus pacotes entregues fora de ordem se os dois caminhos tiverem latências diferentes. A pilha TCP do host recetor irá reordená-los, mas isto causa retransmissões e degradação do throughput na prática — particularmente notável em transferências de ficheiros grandes numa única conexão.

Requisito do switch: As portas do switch devem ser configuradas como um LAG estático (Link Aggregation Group) sem LACP. Sem isto, o switch verá frames do mesmo endereço MAC a chegar em múltiplas portas e pode desencadear um desligamento de proteção contra loops.

Melhor utilização: Cargas de trabalho de transferência em massa com muitas conexões simultâneas de curta duração, onde a reordenação por pacote é tolerável.

Modo 1 — Active-Backup

Apenas uma interface slave está ativa em qualquer momento. Todas as outras estão em estado de espera ativa. Quando o link ativo falha (detetado via monitorização MII ou ARP), o driver de bonding promove um slave de backup e envia um ARP gratuito para atualizar as tabelas de endereços MAC da rede.

Nuance crítica: No modo active-backup, a interface bond apresenta sempre o mesmo endereço MAC à rede (o MAC do slave atualmente ativo). Isto significa que não é necessária nenhuma configuração especial do switch — da perspetiva do switch, é uma conexão normal de host único. Este é o único modo que funciona corretamente em switches sem qualquer configuração LAG.

Tempo de failover: Com `miimon=100`, `downdelay=200`, `updelay=200`, pode esperar um failover em aproximadamente 200–300ms — rápido o suficiente para evitar quedas de sessão TCP na maioria dos casos.

Melhor utilização: Cenários de alta disponibilidade onde a simplicidade e compatibilidade importam mais do que a largura de banda — interfaces de gestão, acesso out-of-band, ou qualquer ambiente onde o switch não está sob o seu controlo.

Modo 2 — Balance-XOR

O tráfego é distribuído usando uma política de hash de transmissão aplicada a cada pacote. O hash padrão é `(source_MAC XOR destination_MAC) modulo slave_count`. Políticas de nível superior (`layer3+4`) utilizam endereços IP e números de porta para melhor distribuição.

A política layer3+4: Configurar `xmit_hash_policy=layer3+4` melhora dramaticamente a distribuição ao fazer hash no IP de origem, IP de destino, porta de origem e porta de destino. Isto garante que diferentes fluxos TCP para o mesmo servidor de destino são distribuídos pelos links, o que o hash baseado em MAC padrão não consegue alcançar.

Requisito do switch: Configuração de LAG estático no switch (igual ao Modo 0), mas sem o problema de reordenação de pacotes, uma vez que todos os pacotes dentro de um único fluxo atravessam a mesma interface.

Melhor utilização: Ambientes que necessitam de balanceamento de carga sem suporte LACP, particularmente quando combinado com a política de hash `layer3+4`.

Modo 3 — Broadcast

Cada pacote é transmitido simultaneamente em todas as interfaces slave. Cada slave envia uma cópia idêntica de cada frame.

Quando isto é realmente útil: O modo broadcast não é sobre largura de banda — é sobre entrega garantida a múltiplos segmentos de rede simultaneamente. É utilizado em cenários especializados de clustering de alta disponibilidade onde dois switches separados ou caminhos de rede devem ambos receber cada pacote (por exemplo, certos sistemas de replicação de armazenamento ou de negociação financeira com tecidos de rede redundantes). Também é utilizado em algumas configurações de monitorização de rede.

O custo de largura de banda: Com duas NICs em modo broadcast, consome 2x a largura de banda no cabo para cada pacote. Com quatro NICs, 4x. Este modo nunca deve ser utilizado para tráfego de uso geral.

Modo 4 — 802.3ad / LACP (Agregação Dinâmica de Links)

Este é o padrão IEEE 802.3ad, implementado via Link Aggregation Control Protocol (LACP). O driver de bonding e o switch trocam PDUs (Protocol Data Units) LACP para negociar dinamicamente quais links formam o grupo de agregação, os seus parâmetros e o seu estado de saúde.

Como funciona a negociação LACP: Cada lado envia LACPDUs anunciando a sua prioridade de sistema, prioridade de porta e chave de agregação. Links com chaves correspondentes em ambos os lados formam um LAG. Se um link falhar, o LACP deteta-o e remove-o do grupo sem qualquer intervenção manual.

Política de hash de transmissão: Tal como o Modo 2, o Modo 4 utiliza uma política de hash para distribuição de carga. A política `layer3+4` é fortemente recomendada aqui também. Note que o LACP não garante balanceamento de carga por pacote — distribui fluxos pelos links, pelo que uma única transferência de ficheiro grande ainda utilizará apenas um link físico.

Configuração do switch: O switch deve ter o LACP ativado no canal de porta correspondente. Modos LACP incompatíveis (active vs. passive) são uma fonte frequente de falhas de bonding. Ambos os lados podem ser definidos para `active` para garantir que a negociação prossiga sempre.

Melhor utilização: Centros de dados, servidores de alto desempenho e qualquer ambiente onde controla a configuração do switch. Este é o padrão de ouro para bonding em produção quando o suporte do switch está disponível.

Modo 5 — Balance-TLB (Balanceamento Adaptativo de Carga de Transmissão)

O Modo 5 distribui o tráfego de saída por todos os slaves com base na carga atual de cada interface (o slave com menor carga recebe o próximo pacote de saída). O tráfego de entrada é recebido apenas num único slave designado.

A principal vantagem: Não é necessária absolutamente nenhuma configuração do switch. A interface bond utiliza diferentes endereços MAC de origem por slave para o tráfego de saída, o que é um comportamento válido que qualquer switch trata de forma transparente.

A limitação: O tráfego de entrada não é balanceado. Se o seu servidor recebe principalmente grandes volumes de dados (um servidor de download, uma réplica de base de dados a receber fluxos de replicação), o Modo 5 não oferece nenhum benefício para essa direção. Se o seu servidor envia principalmente dados, o Modo 5 é altamente eficaz.

Comportamento de failover: Se o slave de receção falhar, outro slave assume o papel de receção. O balanceamento de carga de saída continua pelos slaves restantes.

Modo 6 — Balance-ALB (Balanceamento Adaptativo de Carga)

O Modo 6 estende o Modo 5 adicionando balanceamento de carga de entrada através de negociação ARP. O driver de bonding envia periodicamente respostas ARP com diferentes endereços MAC de origem para diferentes clientes, fazendo com que esses clientes enviem tráfego de retorno para diferentes interfaces slave.

O mecanismo de manipulação ARP: Esta é a parte inteligente. O driver interceta respostas ARP e roda o endereço MAC de origem entre os slaves. Os clientes armazenam em cache estas entradas ARP e direcionam o seu tráfego para qualquer slave MAC que aprenderam. Isto alcança o balanceamento de carga de entrada sem qualquer configuração do lado do switch.

Ressalva prática: O balanceamento de entrada baseado em ARP só funciona para hosts que comunicaram recentemente com o servidor com bonding. Novas conexões chegam sempre ao slave primário até que uma resposta ARP seja enviada. Em cenários de alta taxa de conexão, a distribuição de entrada pode ser desigual.

Melhor utilização: Ambientes sem switches com capacidade LACP que necessitam de balanceamento de carga bidirecional. Uma escolha sólida para ambientes de VPS Hosting onde o switch virtual do hypervisor pode não suportar LACP.

Tabela Comparativa de Modos de Bonding

Configuração do Network Bonding no Linux

Pré-requisitos

“`bash

Verify bonding module is available

modinfo bonding

Load the module if not already loaded

modprobe bonding

“`

Configuração via systemd-networkd (Abordagem Moderna)

Criar `/etc/systemd/network/bond0.netdev`:

“`ini

[NetDev]

Name=bond0

Kind=bond

[Bond]

Mode=802.3ad

TransmitHashPolicy=layer3+4

MIIMonitorSec=100ms

LACPTransmitRate=fast

“`

Criar `/etc/systemd/network/bond0.network`:

“`ini

[Match]

Name=bond0

[Network]

Address=192.168.1.10/24

Gateway=192.168.1.1

“`

Criar `/etc/systemd/network/eth0.network` e `eth1.network`:

“`ini

[Match]

Name=eth0

[Network]

Bond=bond0

“`

Configuração via `/etc/network/interfaces` (Debian/Ubuntu)

“`bash

auto bond0

iface bond0 inet static

address 192.168.1.10

netmask 255.255.255.0

gateway 192.168.1.1

bond-slaves eth0 eth1

bond-mode 4

bond-miimon 100

bond-lacp-rate 1

bond-xmit-hash-policy layer3+4

auto eth0

iface eth0 inet manual

bond-master bond0

auto eth1

iface eth1 inet manual

bond-master bond0

“`

Verificação do Estado do Bond

“`bash

Check bond status and slave states

cat /proc/net/bonding/bond0

Monitor interface statistics

ip -s link show bond0

Check LACP negotiation state (Mode 4)

cat /proc/net/bonding/bond0 | grep -A5 "LACP"

“`

O resultado de `/proc/net/bonding/bond0` é a ferramenta de diagnóstico mais importante. Mostra o slave ativo, o estado do link de cada membro, o estado MII e (para o Modo 4) as informações do parceiro LACP.

Network Bonding em Servidores Dedicados e VPS

Em Servidores Dedicados bare-metal, tem controlo total sobre a configuração de NIC do servidor e (tipicamente) a configuração da porta do switch, tornando o Modo 4 (LACP) a escolha natural para cargas de trabalho de produção. A maioria dos fornecedores de centros de dados pode configurar o LACP nas suas portas de switch mediante pedido.

Para ambientes de VPS com cPanel, a camada de rede virtual do hypervisor trata do bonding subjacente ao nível do host. A VM convidada normalmente vê uma única NIC virtual, mas o host pode estar a executar interfaces físicas com bonding por baixo — fornecendo redundância de forma transparente.

Ao implementar cargas de trabalho intensivas em GPU em infraestrutura de GPU Hosting, o network bonding torna-se crítico para alimentar os nós GPU com dados suficientemente rápido para evitar a privação de I/O. Os pipelines de treino e o serviço de inferência beneficiam ambos da largura de banda agregada que o bonding LACP proporciona.

Armadilhas Comuns e Casos Extremos

Conflitos com o Spanning Tree Protocol (STP): Ao adicionar portas com bonding a um switch, o STP pode bloquear temporariamente as portas durante a negociação. Configure o PortFast (ou equivalente) nas portas do switch para evitar atrasos de 30 segundos durante eventos de ativação de link.

Incompatibilidades de MTU: Todas as interfaces slave num bond devem ter definições de MTU idênticas. Uma incompatibilidade causa perda intermitente de pacotes que é extremamente difícil de diagnosticar. Verifique sempre com `ip link show` após a configuração.

Modos de timeout LACP: O LACP suporta modos de timeout “slow” (30 segundos) e “fast” (1 segundo). Utilize sempre `lacp-rate fast` (`bond-lacp-rate 1`) em produção. O modo slow significa que um link com falha demora até 90 segundos a ser removido do LAG.

Migração ao vivo de máquinas virtuais: Se uma VM com uma interface com bonding for migrada para um host diferente, os endereços MAC do bond podem mudar dependendo do hypervisor. Isto pode causar entradas de cache ARP obsoletas e breve perda de conectividade. Prepare ARPs gratuitos nos seus scripts de migração.

Hash assimétrico: Com o Modo 4 e hash `layer3+4`, o tráfego do servidor A para o servidor B pode atravessar eth0, enquanto o tráfego de retorno de B para A atravessa eth1 no bond de B. Isto é normal e esperado — cada endpoint faz hash independentemente do seu tráfego de saída.

Interferência do NetworkManager: Em sistemas RHEL/CentOS, o NetworkManager pode interferir com bonds configurados manualmente. Configure os bonds através da interface nmcli do NetworkManager ou desative o NetworkManager para as interfaces relevantes usando `NM_CONTROLLED=no` no ficheiro de configuração da interface.

Bonding vs. Outras Técnicas de Rede de Alta Disponibilidade

O network bonding não é a única abordagem para redundância de NIC. Compreender quando usar alternativas é igualmente importante.

MLAG (Multi-Chassis Link Aggregation) merece menção especial: permite que um servidor a executar bonding Modo 4 conecte as suas duas NICs a dois switches fisicamente separados, ambos participando no mesmo LAG lógico. Isto elimina o próprio switch como ponto único de falha — um nível de redundância que o LACP de switch único padrão não consegue fornecer.

Matriz de Decisão: Escolher o Modo de Bonding Correto

Utilize esta estrutura para selecionar o seu modo de bonding:

Controla a configuração do switch?

• Não → Vá para o Modo 1, 5 ou 6
• Precisa de balanceamento de carga bidirecional? → Modo 6
• Tráfego predominantemente de saída? → Modo 5
• Failover puro, máxima simplicidade? → Modo 1
• Sim → Vá para o Modo 0, 2 ou 4
• Precisa de negociação dinâmica e conformidade com as melhores práticas? → Modo 4 (LACP)
• LAG estático, configuração mais simples? → Modo 2 com hash layer3+4
• Requisito de broadcast especializado? → Modo 3

É uma interface de gestão/IPMI? Utilize sempre o Modo 1. Nunca arrisque uma interface de gestão num modo que requer configuração do switch.

Está numa plataforma cloud ou virtual? Verifique se o switch virtual do hypervisor suporta LACP. Se não, o Modo 6 oferece o melhor equilíbrio entre distribuição de carga e compatibilidade.

Para equipas que gerem múltiplos servidores através de Painéis de Controlo VPS, verificar o estado do bonding deve fazer parte da lista de verificação padrão pós-implementação, juntamente com a verificação SSL via Certificados SSL e verificações de propagação DNS após o Registo de Domínios.

Lista de Verificação de Pontos-Chave Técnicos

• Defina sempre `miimon=100` e `downdelay=200 updelay=200` como linha de base para monitorização MII em produção
• Utilize `xmit_hash_policy=layer3+4` com o Modo 2 e Modo 4 para garantir distribuição ao nível do fluxo em vez de ao nível do MAC
• Verifique `/proc/net/bonding/bond0` imediatamente após a configuração — não assuma que está a funcionar
• Configure a taxa LACP para `fast` no Modo 4 para reduzir o tempo de deteção de failover de 90 segundos para 3 segundos
• Certifique-se de que todas as NICs slave têm definições de MTU, velocidade e duplex idênticas antes de as adicionar a um bond
• Em Servidores Dedicados de produção, solicite sempre a configuração LACP ao seu fornecedor de centro de dados em vez de usar LAG estático
• Teste o failover explicitamente desligando um cabo — não assuma que a configuração está correta até ter verificado em condições de falha
• Documente qual NIC física corresponde a qual slave (eth0, eth1) usando `ethtool -i eth0` para evitar confusão durante a manutenção física
• Para redundância entre switches em ambientes críticos, investigue o MLAG antes de se conformar com LACP de switch único

FAQ

O network bonding duplica a velocidade de um único download de ficheiro?

Não. O bonding distribui o tráfego pelos links ao nível do fluxo (ou ao nível do pacote no Modo 0). Uma única conexão TCP utiliza apenas um link físico de cada vez na maioria dos modos. O bonding aumenta o throughput agregado em múltiplas conexões simultâneas, não a velocidade de qualquer conexão individual.

Qual é a diferença entre o bonding Modo 4 (LACP) e um LAG estático?

Um LAG estático (utilizado pelos Modos 0 e 2) define manualmente quais portas formam o grupo de agregação sem negociação. O LACP (Modo 4) negoceia dinamicamente o LAG usando pacotes de controlo, detetando automaticamente configurações incorretas, links com falha e adicionando/removendo membros. O LACP é mais robusto e é o padrão da indústria para implementações de produção.

Posso configurar o network bonding num VPS?

Depende do hypervisor e do fornecedor de alojamento. A maioria das instâncias VPS cloud apresenta uma única NIC virtual ao convidado, com o bonding tratado ao nível do hypervisor. Alguns fornecedores que oferecem VPS semelhante a bare-metal ou instâncias cloud dedicadas suportam bonding ao nível do convidado. Verifique com o seu fornecedor antes de tentar configurar o bonding dentro de um convidado VPS.

O que acontece às conexões ativas quando um link com bonding falha?

No Modo 1 (Active-Backup), o bond envia um ARP gratuito após o failover, atualizando as tabelas MAC do switch. As conexões TCP existentes experimentam uma breve pausa (tipicamente inferior a 300ms com monitorização MII rápida) mas geralmente sobrevivem. No Modo 4, o LACP deteta a falha e redistribui os fluxos pelos links sobreviventes — os fluxos existentes no link com falha terão de ser restabelecidos pela aplicação.

Por que o meu bond Modo 4 mostra apenas um slave ativo em `/proc/net/bonding/bond0`?

A causa mais comum é uma configuração incorreta do lado do switch. Verifique se as portas do switch estão configuradas no mesmo canal de porta com LACP ativado em modo ativo. Verifique também se `lacp-rate` está definido de forma consistente em ambos os lados. Uma chave LACP ou prioridade de sistema incompatível pode impedir a agregação mesmo quando os links físicos estão ativos.