Agrupamento LACP no Linux: configuração, verificação e resolução de problemas

O bonding LACP no Linux combina várias interfaces Ethernet numa única ligação lógica, proporcionando-lhe mais largura de banda agregada e failover automático entre placas de rede físicas. Utiliza a norma IEEE 802.3ad, com ambos os lados (servidor e switch) a negociarem quais as ligações ativas e como o tráfego é distribuído. Este artigo aborda o que o LACP realmente faz, quando o escolher em detrimento dos outros modos de bonding do Linux, como configurá-lo num servidor Linux moderno e como verificar se está a funcionar.

O que é a agregação de ligações e o LACP?

A agregação de ligações combina várias ligações de rede físicas num único canal lógico. Tem dois objetivos: aumentar a largura de banda total disponível em todo o grupo de ligações e fornecer failover automático caso qualquer ligação individual falhe.

O LACP, ou Protocolo de Controlo de Agregação de Ligações, é a versão dinâmica da agregação de ligações definida pela norma IEEE 802.3ad. Em vez de depender de uma configuração estática em ambas as extremidades, o LACP troca pacotes de controlo chamados LACPDUs entre o servidor e o switch. Os dois lados negociam quais as ligações que se juntam à agregação, monitorizam o estado de cada ligação e incluem ou excluem membros do grupo à medida que as condições mudam.

Num contexto Linux, o LACP funciona como modo 4 (802.3ad) do controlador de bonding do kernel. O controlador cria uma interface lógica (normalmente bond0) que detém o endereço IP, enquanto as interfaces físicas como eth0 e eth1 tornam-se subordinadas da ligação. Do ponto de vista do SO, existe uma única interface de rede. Do ponto de vista da ligação física, existem múltiplas ligações Ethernet paralelas.

Algumas coisas que o LACP especificamente não faz, mas que as pessoas frequentemente esperam:

• Uma única ligação TCP continua a transitar por uma ligação física. O LACP equilibra fluxos, não pacotes dentro de um fluxo. Duas ligações 1 GbE em bonding não farão com que um único download seja mais rápido do que 1 Gbps.
• O LACP requer um switch que suporte 802.3ad. Não formará uma ligação com um switch não gerido ou que não suporte LACP.
• Todas as ligações membros devem funcionar à mesma velocidade e no mesmo modo duplex. Não é possível ligar uma porta de 1 GbE a uma porta de 10 GbE.

Modos de bonding do Linux: quando utilizar o LACP

O controlador de bonding do Linux suporta sete modos. A maioria das implementações em produção utiliza um destes três.

Modo 1: ativo-backup

Uma interface membro está ativa, as outras permanecem inativas. Se a ativa falhar, outra assume o controlo em poucas centenas de milissegundos. Não é necessária qualquer configuração do switch, o que torna esta a escolha certa quando os switches estão fora do seu controlo ou não suportam 802.3ad. Obtém redundância, mas sem largura de banda adicional.

Modo 4: 802.3ad (LACP)

Todos os membros transportam tráfego. O controlador de ligação e o switch utilizam LACP para negociar o conjunto ativo e detetar falhas. O tráfego de saída é equilibrado entre os membros utilizando uma política de hash que configura. Esta é a escolha padrão para servidores dedicados ligados a switches geridos quando pretende tanto redundância como largura de banda adicional para cargas de trabalho com múltiplos fluxos.

Modo 6: balance-alb

Equilíbrio de carga adaptativo em ambas as direções, sem necessidade de suporte do switch. O driver intercepta respostas ARP para reescrever endereços MAC e distribuir o tráfego de entrada. Funciona, mas é frágil em comparação com o LACP. Utilize-o apenas quando for realmente impossível configurar o lado do switch.

Regra de decisão:

• Sem switch gerido, ou se apenas necessitar de failover: modo 1 (active-backup).
• Switch gerido, múltiplos fluxos, pretende largura de banda e redundância: modo 4 (LACP).
• Não é possível utilizar um switch gerido, mas necessita de equilíbrio em ambas as direções: modo 6 (balance-alb).

Os modos 0 (balance-rr), 2 (balance-xor), 3 (broadcast) e 5 (balance-tlb) existem, mas raramente são a escolha certa em hardware moderno. Escolha o modo 1 ou o modo 4, a menos que tenha uma razão específica para não o fazer.

Configurar a ligação LACP no Linux

Nos sistemas Ubuntu e Debian modernos, o LACP é configurado através do netplan. No RHEL, CentOS Stream, AlmaLinux e Rocky Linux, utilize o NetworkManager através nmcli ou editando os ficheiros de ligação subjacentes.

Netplan (Ubuntu, Debian)

Insira o seguinte em /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Em seguida, aplique com netplan apply. Os parâmetros principais:

• mode: 802.3ad ativa o LACP.
• lacp-rate: fast envia LACPDUs a cada segundo, em vez do padrão de 30 segundos. Deve corresponder à configuração do switch.
• mii-monitor-interval: 100 verifica o estado da ligação a cada 100 ms.
• transmit-hash-policy: layer3+4 distribui os fluxos por IP de origem/destino e porta TCP/UDP. Isto produz um melhor equilíbrio do que a layer2 para tráfego típico da Web e de bases de dados.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Lado do switch

O switch necessita de um grupo LAG (frequentemente chamado de canal de porta) configurado para o modo ativo LACP, com o mesmo número de portas membros que o bond. A sintaxe exata varia consoante o fornecedor, mas os requisitos não: as portas devem estar na mesma VLAN, definidas para a mesma velocidade e duplex, e utilizar o modo ativo LACP em pelo menos um dos lados. Ter ambos os lados ativos é a configuração mais segura.

No Cisco IOS:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

No Aruba/ProCurve:

trunk 1-2 trk1 lacp

A lacp_rate configuração no switch deve corresponder à do host. Uma incompatibilidade aqui é um dos erros de configuração LACP mais comuns e causa oscilações intermitentes a cada 30 segundos.

Verificação e resolução de problemas do LACP

Verifique o estado ativo da ligação no lado Linux:

cat /proc/net/bonding/bond0

Quatro aspetos a verificar na saída:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation confirma que o modo 4 está carregado.
2. Cada interface subordinada listada com MII Status: up e link failure count: 0.
3. Um valor diferente de zero Partner Mac Address para cada subordinada. Se aqui aparecerem apenas zeros, significa que o switch não está a enviar pacotes LACP, quer porque a porta não está num LAG com LACP ativo, quer porque o cabo está na porta errada.
4. Aggregator ID é o mesmo em todos os membros. IDs diferentes significam que os membros não estão realmente combinados, estão a agir de forma independente.

A verificação mais rápida para confirmar se a largura de banda está a ser utilizada é executar o iperf3 com vários fluxos paralelos (iperf3 -P 8) a partir de outro host. Se a taxa de transferência total exceder a capacidade de um único link, o LACP está a equilibrar corretamente. Um teste de fluxo único que mostra a velocidade de um link é o comportamento esperado, não um bug.

Os problemas mais comuns do LACP e as suas causas:

• O MAC do parceiro é todo zeros: a porta do switch não está num LAG com LACP ativo, ou os cabos estão mal ligados.
• A ligação é estabelecida, mas a taxa de transferência fica limitada a um único link: a política de hash provavelmente foi definida por predefinição para layer2, que faz o hash apenas no MAC de destino. Mude para layer3+4.
• Flutuação intermitente a cada 30 segundos: lacp_rate incompatibilidade entre o host e o switch.
• Um subordinado funciona, mas o outro nunca transporta tráfego: incompatibilidade de velocidade/duplex, ou as portas do switch não estão no mesmo grupo LAG no lado do switch.

Quando o LACP não é a resposta certa

O LACP resolve um problema específico: agregar múltiplas ligações entre um anfitrião e um comutador (ou uma pilha de comutadores) para obter redundância e largura de banda por fluxo. Existem cenários em que não é a ferramenta certa.

Se precisar apenas de redundância e os switches não suportarem 802.3ad, utilize o modo 1 (ativo-backup) em vez disso. Funciona com qualquer coisa.

Se precisar de ligar dois switches separados para obter redundância ao nível do chassis, o LACP padrão não abrange dois switches não relacionados. Precisa de Multi-Chassis Link Aggregation (MLAG), em que dois switches se apresentam como um único parceiro LACP lógico. A maioria dos fornecedores de switches empresariais implementa isto sob o seu próprio nome: Cisco vPC, Arista MLAG, Juniper MC-LAG.

Se precisar que um único fluxo exceda a largura de banda de uma ligação, o LACP não consegue fazer isso. As opções são utilizar uma ligação física mais rápida (substituir 2x 10 GbE por 1x 25 GbE ou 1x 40 GbE) ou utilizar uma tecnologia completamente diferente. O SR-IOV proporciona um desempenho de fluxo único próximo da velocidade da linha às máquinas virtuais, atribuindo a cada VM uma NIC virtual acelerada por hardware, mas resolve um problema diferente e tem as suas próprias limitações. Esse é um tema para um artigo separado.

Para a maioria dos servidores dedicados e de colocalização que lidam com muitas ligações simultâneas, o LACP continua a ser a resposta padrão. Duas ligações 10 GbE em modo bonded com layer3+4 hashing lidam confortavelmente com mais de 18 Gbps de tráfego agregado em muitos fluxos, ao mesmo tempo que sobrevivem a uma falha de NIC ou de cabo sem perder um pacote.