Dia 27: Bridging e Bonding no Linux — bridge, bond e team
Neste artigo
1. Introdução ao Bridging e Bonding
No Dia 1 do curso vimos o modelo OSI e o conceito de camada 2 (ligação de dados). Hoje aprofundamos essa camada com três tecnologias fundamentais em Linux para gestão de interfaces de rede: bridging, bonding e teaming. Estas técnicas permitem criar infra-estruturas de rede mais flexíveis, redundantes e de elevado desempenho.
O bridging funciona como um switch virtual em software — liga duas ou mais interfaces de rede na mesma rede lógica, permitindo que dispositivos em segmentos físicos diferentes comuniquem como se estivessem no mesmo domínio de difusão. É essencial em virtualização (KVM, LXC), onde as máquinas virtuais precisam de acesso directo à rede física.
O bonding agrega duas ou mais interfaces físicas numa única interface lógica, oferecendo redundáncia (se um cabo falha, o outro mantém a ligação) e, em alguns modos, aumento de largura de banda. O teaming é uma alternativa moderna ao bonding, com arquitectura modular e melhor desempenho em sistemas multi-core.
No Dia 16 abordámos VLANs, que operam igualmente na camada 2. Bridging e bonding são complementares: é possível criar um bond e depois colocá-lo como porta de uma bridge, combinando redundáncia e segmentação.
| Tecnologia | Função principal | Caso de uso típico |
|---|---|---|
| Bridge | Switch virtual L2 | Virtualização (KVM, LXC) |
| Bond | Agregação de links | Redundância de NICs |
| Team | Alternativa moderna ao bond | Servidores multi-core |
2. Bridging — Switch Virtual em Linux
Uma bridge Linux opera como um switch de camada 2. Aprende endereços MAC das interfaces conectadas e encaminha tráfego entre elas com base nessa tabela. Ao contrário do encaminhamento, não modifica o cabeçalho Ethernet — os pacotes atravessam a bridge de forma transparente.
O comando ip link add … type bridge cria a bridge, e ip link set … master br0 adiciona interfaces como portas. É necessário que o módulo bridge esteja carregado no kernel (normalmente já está em distribuições modernas).
# Criar bridge br0
ip link add name br0 type bridge
# Adicionar interfaces como portas
ip link set eth0 master br0
ip link set eth1 master br0
# Activar bridge e atribuir IP
ip link set br0 up
ip addr add 192.168.1.10/24 dev br0
# Verificar bridge
bridge link show
bridge fdb show br0O comando bridge link show lista as portas da bridge e o seu estado, enquanto bridge fdb show mostra a tabela de encaminhamento (endereços MAC aprendidos). Esta tabela é dinâmica — entradas expiram após 300 segundos por defeito.
Em ambientes de virtualização, a bridge é o elemento central: as interfaces virtuais (vnet0, vnet1) são adicionadas como portas da bridge, e as VMs obtêm endereços directamente do DHCP da rede física, sem NAT.
STP — Spanning Tree Protocol
A bridge Linux suporta STP (Spanning Tree Protocol) para evitar loops em topologias redundantes. Por defeito, STP está activo quando se cria uma bridge. Para verificar o estado, use bridge link show — procure o campo root_id e bridge_id. Para desactivar STP (apenas em ambientes controlados sem loops): ip link set br0 type bridge stp_state 0.
3. Bonding — Agregar Ligações Físicas
O bonding combina múltiplas interfaces de rede numa só. A interface resultante (bond0) apresenta um único endereço MAC e IP, e o kernel distribui o tráfego pelas interfaces físicas subordinadas conforme o modo seleccionado. Isto oferece dois benefícios: redundância (tolerância a falhas de cabo/NIC) e aumento de largura de banda (em modos que suportam agregação).
O bonding requer o módulo bonding no kernel. A configuração manual com iproute2 é directa: cria-se a interface bond, definem-se as interfaces físicas como subordinadas e activa-se.
# Criar bond0 em modo 802.3ad (LACP)
ip link add bond0 type bond mode 802.3ad
# Adicionar interfaces físicas
ip link set eth0 master bond0
ip link set eth1 master bond0
# Activar bond e atribuir IP
ip link set bond0 up
ip addr add 192.168.1.10/24 dev bond0
# Verificar estado do bonding
cat /proc/net/bonding/bond0O ficheiro /proc/net/bonding/bond0 é a fonte de verdade para diagnosticar bonding. Mostra o modo activo, interfaces subordinadas, estado de cada uma (up/down), estatísticas de pacotes e eventos de failover. Em caso de problema, é sempre o primeiro comando a executar.
ℹ Redundância sem switch gerido
O bonding active-backup dá redundância sem necessidade de configuração no switch — ideal para PME sem switches geridos.
4. Modos de Bonding
O bonding suporta sete modos de operação, cada um com requisitos e comportamentos distintos. A escolha do modo correcto depende do hardware disponível (especialmente das capacidades do switch) e dos objectivos: redundância, largura de banda ou ambos.
| Modo | Nome | Switch requerido | Largura de banda |
|---|---|---|---|
| 0 | balance-rr | Não (padrão) | Soma de todas as NICs |
| 1 | active-backup | Não | 1 NIC |
| 2 | balance-xor | Não (padrão) | Soma de todas as NICs |
| 3 | broadcast | Não (padrão) | 1 NIC (tudo em todas) |
| 4 | 802.3ad (LACP) | Sim (LACP) | Soma de todas as NICs |
| 5 | balance-tlb | Não | Soma (saída) |
| 6 | balance-alb | Não | Soma (saída + entrada) |
Modos mais utilizados
active-backup (modo 1) é o mais simples e robusto: apenas uma interface está activa de cada vez. Se falha, a outra assume imediatamente. Não requer configuração no switch, o que o torna ideal para ambientes sem switches geridos. A desvantagem é que só se usa uma NIC de cada vez — sem aumento de largura de banda.
802.3ad LACP (modo 4) é o padrão IEEE para agregação de links. Requer que o switch suporte e esteja configurado para LACP. Oferece verdadeiro aumento de largura de banda (soma das NICs) e redundância. É o modo recomendado em centros de dados e ambientes empresariais com switches geridos.
balance-rr (modo 0) round-robin distribui pacotes sequencialmente pelas NICs. Aumenta a largura de banda mas pode causar reordenação de pacotes (fora de ordem), o que afecta o desempenho de TCP em alguns casos. Não requer configuração no switch mas nem todos os switches toleram este comportamento.
⚠ LACP requer configuração no switch
O modo 802.3ad (LACP) requer configuração no switch — se o switch não suportar LACP, o bonding não funciona correctamente.
A documentação oficial do kernel Linux descreve todos os modos em detalhe: kernel.org — bonding.txt. É a referência autoritativa para parâmetros avançados como miimon (frequência de monitorização do link), downdelay/updelay (tempos de transição) e lacp_rate (frequência de PDUs LACP).
5. Teaming — Alternativa Moderna
O teaming é uma alternativa ao bonding desenvolvida pela Red Hat com uma arquitectura diferente. Enquanto o bonding é implementado como um módulo do kernel, o teaming usa um processo em espaço de utilizador (teamd) para a lógica de controlo e uma pequena porção no kernel para o caminho de dados. Isto oferece várias vantagens.
A principal vantagem do teaming é o paralelismo multi-core: o bonding processa todo o tráfego numa única thread, enquanto o teaming distribui o processamento por múltiplas CPUs. Em servidores com interfaces de 10 Gbps ou superior, isto faz diferença significativa. Adicionalmente, o teaming tem uma arquitectura modular com “runners” (equivalentes aos modos de bonding) carregáveis dinamicamente.
O teaming suporta os mesmos modos principais do bonding: activebackup, loadbalance, roundrobin, broadcast e lacp (equivalente ao 802.3ad). A configuração é feita através de um ficheiro JSON e o daemon teamd.
# Iniciar teamd com configuração
teamd -d -f /etc/teamd/team0.conf
# Verificar estado do team
teamdctl team0 state
# Configuração típica (ficheiro JSON)
# /etc/teamd/team0.conf:
# {
# "device": "team0",
# "runner": {"name": "activebackup"},
# "link_watch": {"name": "ethtool"},
# "ports": {"eth0": {}, "eth1": {}}
# }O comando teamdctl team0 state mostra o estado detalhado do team, incluindo a porta activa, estado de cada interface e estatísticas. A saída em JSON é mais estruturada que /proc/net/bonding/bond0 e integra-se melhor com scripts de monitorização.
6. Configuração com NetworkManager
Em sistemas modernos (RHEL 8+, Fedora, Ubuntu 22.04+), o NetworkManager é a ferramenta padrão para gestão de redes. O nmcli suporta bridges, bonds e teams nativamente, com configuração persistente (sobrevive a reinicializações).
Bridge com nmcli
# Criar bridge br0
nmcli con add type bridge con-name br0 ifname br0
# Adicionar portas à bridge
nmcli con add type bridge-slave con-name br0-eth0 ifname eth0 master br0
nmcli con add type bridge-slave con-name br0-eth1 ifname eth1 master br0
# Activar bridge
nmcli con up br0
# Atribuir IP estático
nmcli con mod br0 ipv4.addresses 192.168.1.10/24
nmcli con mod br0 ipv4.method manual
nmcli con up br0Bonding com nmcli
# Criar bond0 em modo 802.3ad
nmcli con add type bond con-name bond0 ifname bond0 mode 802.3ad
# Adicionar interfaces ao bond
nmcli con add type ethernet con-name bond0-eth0 ifname eth0 master bond0
nmcli con add type ethernet con-name bond0-eth1 ifname eth1 master bond0
# Atribuir IP e activar
nmcli con mod bond0 ipv4.addresses 192.168.1.10/24
nmcli con mod bond0 ipv4.method manual
nmcli con up bond0Para teaming com NetworkManager, o processo é similar: nmcli con add type team con-name team0 ifname team0 config '{"runner":{"name":"activebackup"}}' cria o team, e as portas são adicionadas com type team-slave.
Uma vantagem do NetworkManager é a persistência automática: todas as configurações ficam guardadas em /etc/NetworkManager/system-connections/ e são restauradas após reinício. Com comandos ip directos, é necessário criar ficheiros ifcfg-* ou unidades systemd-networkd manualmente.
7. Erros Comuns e Lista de Verificação
A configuração de bridges, bonds e teams envolve vários pontos de falha possíveis — desde incompatibilidades de switch até configuração incorrecta de parâmetros. Abaixo os problemas mais frequentes e uma lista de verificação para os evitar.
| Sintoma | Causa provável | Solução |
|---|---|---|
| Bond não agrega largura de banda | Modo não-LACP ou switch sem LACP | Mudar para 802.3ad e configurar LACP no switch |
| Failover não detecta falha de cabo | miimon desactivado ou valor muito alto | Definir miimon=100 (100ms) |
| VMs sem acesso à rede na bridge | IP atribuído à interface física em vez da bridge | Mover IP de eth0 para br0 |
| LACP não negoceia com switch | lacp_rate incorrecto ou xmit_hash_policy | Verificar lacp_rate=1 e xmit_hash_policy=layer2+3 |
| Configuração perdida após reinício | Comandos ip sem persistência | Usar nmcli ou ficheiros systemd-networkd |
Lista de verificação pré-produção
Antes de colocar uma bridge, bond ou team em produção, verificar cada ponto abaixo:
- Modo de bonding correcto — confirmar que o modo escolhido é compatível com as capacidades do switch (LACP requer switch gerido).
- miimon configurado — definir
miimon=100para detecção rápida de falhas de link (100ms). - IP na interface correcta — em bridges, o IP vai na bridge (br0), nunca na porta física. Em bonds, o IP vai no bond (bond0).
- STP activo em bridges redundantes — se houver múltiplos caminhos, STP evita loops. Confirmar com
bridge link show. - Persistência da configuração — testar reinício e verificar que a configuração sobrevive. Usar nmcli ou systemd-networkd.
- Teste de failover — desligar um cabo fisicamente e confirmar que a ligação se mantém. Verificar tempo de recuperação.
- Verificar /proc/net/bonding/ — confirmar que ambas as interfaces aparecem como “up” e que o modo está correcto.
- Endereço MAC consistente — em bonds, o MAC da interface lógica deve ser consistente após reinício para evitar conflitos ARP.
Com estas práticas, a sua infra-estrutura de rede Linux ficará redundante e preparada para falhas de hardware. No Dia 26: Encaminhamento em Linux — ip route, Policy Routing, VRF continuámos a explorar tecnologias de rede avançadas, e no próximo dia fechamos a série com consolidação e revisão geral.