Configurar e testar um LAG com LACP no Sophos Firewall

Um Link Aggregation Group (LAG) agrupa duas a quatro portas físicas numa única interface lógica. Active-Backup proporciona redundância com um link ativo. 802.3ad (LACP) utiliza vários links em paralelo e aumenta a largura de banda agregada através de várias ligações.

Termos como NIC teaming, NIC bonding, EtherChannel ou trunking também descrevem o agrupamento de links. O nome, por si só, não confirma LACP nem um modo compatível. Um trunk VLAN transporta várias VLANs e não é automaticamente um LAG.

Uma única ligação TCP ou UDP normalmente não fica mais rápida com LACP: o hash mantém cada fluxo num único link membro. A capacidade adicional só surge com várias ligações que produzem hashes diferentes.

Preparar o modo e a migração

Active-Backup ou 802.3ad

O Active-Backup é o modo de redundância mais simples. Apenas um membro transmite tráfego; em caso de falha, outro assume a função. O switch não precisa de um port-channel LACP. No entanto, ambas as portas do switch têm de utilizar as mesmas VLANs ou a mesma configuração access, estar na mesma rede Layer 2 e aceitar a mudança de MAC durante o failover.

O 802.3ad (LACP) utiliza todos os links ativos para distribuição de carga e failover. Aplicam-se os seguintes requisitos:

• O LACP está ativado na firewall e no switch.
• Todos os membros têm o mesmo tipo de interface, a mesma velocidade e Full-Duplex.
• As portas do switch pertencem ao mesmo peer LACP lógico e ao mesmo port-channel.
• Dois switches físicos só funcionam se um stack, MLAG/MC-LAG ou uma tecnologia equivalente os apresentar como um único sistema LACP.
• A configuração VLAN/trunk e a MTU são consistentes em todos os membros.

Para obter apenas redundância, o Active-Backup é geralmente mais simples. O LACP é adequado quando várias ligações paralelas precisam efetivamente de mais largura de banda total.

Verificar os membros e preparar a reversão

O Sophos Firewall permite duas a quatro interfaces físicas não associadas com atribuição de IP estática como membros do LAG. As interfaces PPPoE, Cellular WAN e WLAN estão excluídas.

As portas uplink existentes não são migradas automaticamente ao criar o LAG. VLANs, Zone Binding, DNS, gateways, SD-WAN, Interface Hosts, Dynamic DNS, NAT e routing podem depender da interface antiga. Antes da migração:

1. Em Object usage, atualizar as dependências com Refresh e documentá-las.
2. Preparar um backup, uma janela de manutenção e um plano de reversão concreto.
3. Testar um acesso de administração independente.
4. Planear VLANs, trunks do switch, interfaces NAT, routing e gateways para o novo LAG.
5. Só depois remover de forma controlada os futuros membros das associações existentes.

Planear zonas e interfaces no Sophos Firewall explica que Zone deve ser atribuída ao LAG. O exemplo utilizado ao longo deste artigo é:

PortF2 + PortF4 → LAG0 → VLAN 10 Clientes e VLAN 20 Servidores

Criar o LAG no WebAdmin

Criar o LAG no SFOS 22 da seguinte forma:

1. Abrir Network > Interfaces.
2. Selecionar Add interface > Add LAG.
3. Em Name, introduzir um nome de apresentação descritivo com um máximo de 58 caracteres, por exemplo LAG_Core_Uplink.
4. Definir um Hardware name com um máximo de 10 caracteres de A-Z, a-z, 0-9 e underscore, por exemplo lag_core. Não pode ser alterado posteriormente nem conter nomes reservados como all, gre, eth ou WLAN.
5. Em Member interface, adicionar duas a quatro portas preparadas, no exemplo PortF2 e PortF4.
6. Em Bonding mode, escolher Active-Backup ou 802.3ad.
7. Atribuir a Zone adequada.
8. Configurar IP assignment para IPv4 e, se necessário, IPv6. Para atribuir o endereço ao LAG lógico, escolher entre Static e DHCP. Com Static, introduzir o endereço IP previsto e selecionar a máscara de rede para IPv4 ou o prefixo para IPv6. Esta escolha aplica-se à interface lógica; o requisito de atribuição de IP estática para os membros físicos é independente.
9. Em Advanced settings > Port settings, verificar Link mode, Auto-negotiation for media type e Forward Error Correction (FEC) consoante o modelo. Show recommended settings, seguido de Load recommended configuration, aplica os valores de porta recomendados.
10. Em Advanced settings > Interface settings, verificar MTU e, se necessário, Override MSS. Com 802.3ad, definir também a Xmit hash policy.
11. Utilizar o endereço MAC predefinido do primeiro membro ou substituí-lo apenas quando existir um requisito de design claro. Uma reposição de fábrica devolve um endereço substituído ao endereço MAC predefinido, pelo que este não deve ser a única base para uma lógica externa de port security ou autorização.
12. Selecionar Save.

Distinguir Name de Hardware name: O nome de apresentação pode ser alterado posteriormente e aparece nas outras definições em vez do nome de hardware. O nome de hardware é imutável. Além dos exemplos anteriores, as seguintes cadeias estão reservadas pelo sistema e não podem estar contidas no nome de hardware:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0,
tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm,
USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host,
reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink

Não copiar cegamente os campos de gateway: O procedimento LAG de SFOS 22 e 23 indica Gateway name para membros de bridge com portas WAN e também Gateway IP com endereçamento estático. Essa referência ao bridge é ambígua no contexto de um LAG. Não significa que cada LAG precise de um gateway. Para o uplink VLAN ilustrado, manter o plano de gateways e routing de cada rede; para um LAG WAN, comparar os campos efetivamente apresentados com a configuração WAN prevista e esclarecer qualquer dúvida com o Sophos Support antes de guardar.

MTU e MSS são limites diferentes: A MTU limita o tamanho dos pacotes na interface; Override MSS diz respeito à quantidade máxima de dados úteis TCP por segmento. Alterá-los não é uma solução geral para LACP e deve responder a um requisito fundamentado de MTU do percurso. Diferenças de velocidade ou duplex em relação ao peer também podem causar erros, desconexões, maior latência ou baixo débito. Load recommended configuration carrega os valores de porta recomendados, não simplesmente quaisquer valores suportados; verificar a compatibilidade com o switch e assegurar a via de recuperação antes de os aplicar.

Em seguida, a interface lógica, por exemplo lag0, aparece em Network > Interfaces. As VLANs são depois criadas utilizando o LAG como Parent. Configurar e testar uma VLAN no Sophos Firewall descreve o procedimento para VLAN ID, Zone, gateway, DHCP e validação.

⚠️ A descrição do problema verificada para este procedimento associa NC-94073 a SFOS 19.0.0 GA-Build317 (19.0.0.317) [Tupai]; no momento da verificação não indicava uma versão com correção. Identifica como afetado apenas XGS Appliance com uma interface 10G. Isto não demonstra que o SFOS 22 seja afetado. Não alterar preventivamente a definição. Se uma porta ou um LAG XGS Appliance 10G com SFOS 22 apresentar a mesma falha com Auto-negotiation, registar primeiro o build SFOS, os valores anteriores de Link mode e Auto-negotiation e a configuração do peer, garantindo um acesso independente. Numa janela de manutenção pode testar-se no WebAdmin o workaround da Sophos 10000 Mbps – Full-Duplex; o peer deve corresponder. A alteração pode interromper o link. Depois, verificar estado do link, acessibilidade e contadores de erros. Se não resultar, repor os valores registados em ambas as extremidades e fornecer os dados ao Sophos Support. Este workaround não foi testado aqui em XGS Appliance 10G.

Não utilizar a Device Console como receita de alteração

O SFOS 22 oferece opções lag-interface alteráveis para LACP rate, static mode, Xmit Hash Policy e link monitoring. Após iniciar sessão, o contexto exato é Main Menu > 4. Device Console. Os intervalos aceites são 0 a 10000 milissegundos para down-delay, monitor-interval e up-delay, e 0 a 255 para garp-count; não são recomendações.

No entanto, a referência pública não fornece um comando completo só de leitura para os valores LAG atuais, nem os respetivos valores predefinidos ou um reset documentado. Também usa monitor-interval na sintaxe, mas monitor-interface no texto. Por isso, este artigo não inclui deliberadamente um comando set network lag-interface pronto a copiar: sem um valor anterior fiável e um caminho de recuperação explícito, a alteração de um uplink de produção não seria reproduzível em segurança.

Se o Sophos Support prescrever uma alteração deste tipo para um build SFOS 22 específico, assegurar primeiro um backup e um caminho de gestão independente e registar estado do LAG e do switch, perda de pacotes e todos os valores anteriores confirmados pelo suporte. Na Device Console, usar Tab e ? para verificar a sintaxe do build, alterar apenas os valores aprovados e depois testar estado do link e LACP, logs do switch, GARP/MAC Move, perda de pacotes e falha e recuperação de cada membro. Para reverter, definir explicitamente os valores registados; se não estiverem disponíveis, parar antes da alteração CLI.

Escolher corretamente a Xmit Hash Policy

Com 802.3ad, a Xmit Hash Policy determina através de que membro o Sophos Firewall envia o tráfego de saída. O tráfego de entrada para a firewall é distribuído pelo switch com a sua própria hash policy. Por isso, os algoritmos não têm de ser idênticos: cada lado decide de forma independente para a sua direção de transmissão.

• Layer2: utiliza os endereços MAC de origem e destino. Com poucos pares de MAC, um membro pode ficar muito mais sobrecarregado.
• Layer2+3: considera também os endereços IP de origem e destino e costuma ser um bom ponto de partida para tráfego de rede misto.
• Layer3+4: utiliza adicionalmente informações da camada de transporte. Isto pode distribuir melhor várias ligações entre os mesmos hosts. No entanto, em tráfego fragmentado, a informação das portas pode não estar disponível; os fragmentos podem receber um hash diferente e causar Packet Reordering.

Nenhuma policy distribui um único fluxo por todos os links. Por isso, a escolha adequada deve ser verificada com tráfego real e os contadores dos membros em ambas as direções, não através de um nome de hash idêntico no switch.

Configurar o lado do switch

Com Active-Backup, as portas não são agrupadas num port-channel estático ou LACP. Ambas recebem a mesma configuração VLAN/trunk e conduzem à mesma rede Layer 2. Também deve verificar-se se Spanning Tree, Port Security ou as definições de MAC Move atrasam ou bloqueiam desnecessariamente a transição.

Com 802.3ad, as portas do switch têm de:

• estar no mesmo port-channel LACP,
• utilizar LACP ativamente,
• corresponder à firewall em velocidade, duplex, VLANs e MTU,
• pertencer a um único sistema LACP lógico quando são utilizados dois switches.

Não basta criar o LAG apenas na firewall. Se o switch continuar a tratar as portas separadamente ou utilizar bonding estático em vez de LACP, podem ocorrer perda de pacotes, comportamento assimétrico ou um LAG apenas parcialmente ativo.

Validar o LAG e o failover

Antes do primeiro teste de falha, documentar o estado inicial, o estado dos membros, o estado LACP e os contadores das interfaces na firewall e no switch. Depois:

1. Funcionamento normal: testar o gateway, destinos internos e serviços necessários em ambas as direções.
2. Desligar cada membro individualmente: medir a acessibilidade, a perda de pacotes, as sessões existentes e o tempo de transição. Um failover não é automaticamente totalmente livre de interrupções.
3. Voltar a ligar o membro: verificar na firewall e no switch se é novamente ativado e se os contadores de erros permanecem estáveis.
4. Testar LACP com vários fluxos: gerar várias ligações com combinações de origem/destino diferentes em ambas as direções e comparar os contadores dos membros.
5. Verificar as VLANs: no exemplo, testar individualmente a VLAN 10 e a VLAN 20 quanto a gateway, destinos permitidos, destinos bloqueados, DHCP e DNS.

Para Layer3+4, pode utilizar-se, por exemplo, iPerf3 com quatro fluxos paralelos num cliente de teste fora da firewall, em vez de uma única ligação, porque as respetivas portas são diferentes:

iperf3 -c 10.20.20.50 -P 4 -t 30
iperf3 -c 10.20.20.50 -P 4 -t 30 -R

Substituir 10.20.20.50 pelo endereço do servidor de teste iPerf3. Com Layer2 ou Layer2+3, são necessários vários pares de hosts de origem/destino ou diferentes endereços MAC ou IP. O teste gera deliberadamente carga e deve ser realizado numa janela adequada. -R testa a direção oposta. Testar o desempenho do Sophos Firewall com iPerf3 descreve a configuração completa dos endpoints.

Erros comuns

• O membro não aparece: a porta ainda está associada, não está configurada estaticamente ou pertence a um tipo de interface excluído.
• O LACP não fica ativo: comparar o port-channel do switch, o modo LACP, a associação dos membros, velocidade/duplex, VLANs e MTU.
• Dois switches, mas sem um peer LACP comum: falta um stack ou MLAG/MC-LAG. Limitar o LACP a um peer lógico ou planear o Active-Backup de forma adequada.
• O link XGS Appliance 10G permanece down com Auto-negotiation: verificar a nota específica da versão sobre NC-94073 acima, registar os valores anteriores e testar o workaround apenas numa janela de manutenção controlada.
• A carga permanece quase toda num membro: com poucos fluxos, isto pode estar correto. Testar várias ligações adequadas e comparar os contadores de ambas as direções de transmissão; a hash policy do switch não precisa de ter o mesmo nome.
• A VLAN ou a Internet deixa de funcionar após a migração: verificar VLAN Parent, Zone, objetos de rede, interfaces NAT inbound/outbound, routing e gateways. As regras de firewall normais correspondem a zonas e redes, não a uma porta física membro.
• O failover perde pacotes ou sessões: medir o tempo de transição e verificar no switch as definições de MAC Move, Spanning Tree e Port Security.
• O Hardware name está errado: o nome técnico não pode ser alterado posteriormente; se for necessário mudar o nome, o LAG tem de ser recriado.

Checklist operacional

• Active-Backup ou 802.3ad escolhido de acordo com o objetivo de redundância e largura de banda
• duas a quatro interfaces físicas membro, não associadas e estáticas, preparadas
• Object Usage, backup, plano de reversão e acesso de administração independente verificados
• portas do switch configuradas adequadamente para Active-Backup ou LACP
• Link mode, Auto-negotiation, FEC, MTU e MSS verificados
• Xmit Hash Policy interpretada apenas para a direção de transmissão da firewall
• falha e recuperação de cada membro testadas
• LACP verificado com vários fluxos em ambas as direções e com contadores dos membros
• VLAN Parents, Zone, NAT, routing e gateways validados após a migração

FAQ