Agrupe as duas portas físicas do mesmo par de bypass de hardware no mesmo bond, e o relé de bypass que deveria manter o tráfego fluindo quando o WAF falha parece perfeitamente configurado — e mesmo assim não funciona. Este é o pareamento de interfaces do qual o bypass de hardware realmente depende, as configurações de LACP que precisam coincidir antes mesmo de a agregação negociar, e como provar que o bypass funciona antes de confiar nele em produção.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O modo de falha aqui não é uma configuração ausente — são dois recursos que parecem corretos e que se anulam silenciosamente um ao outro.
O bypass de hardware existe por um único motivo: manter o tráfego de negócio fluindo através de um WAF transparente em linha mesmo que o dispositivo perca energia ou trave. Em um WAF com quatro portas compatíveis com bypass, é tentador tratar a agregação de links como uma decisão puramente lógica — agrupar as portas vizinhas em um bond, interligar os dois bonds, pronto. É exatamente esse instinto que quebra o bypass, porque as duas portas físicas dentro de um mesmo par de relé de bypass são fixas no hardware e não se importam com o seu agrupamento lógico.
A seguir está o pareamento de interfaces do qual o bypass realmente depende, a fiação que mantém o curto-circuito físico e a ponte lógica apontando na mesma direção, as configurações de negociação LACP que precisam coincidir antes mesmo de a agregação subir, as armadilhas que respondem pela maioria desses chamados, e respostas de campo para as perguntas que aparecem constantemente.
Duas portas físicas formam um par de bypass, quer você as tenha colocado no mesmo bond ou não — o relé não sabe nem se importa com o seu agrupamento lógico.
Nas portas compatíveis com bypass deste WAF, s1p1↔s1p2 é um par de relé de hardware e s1p3↔s1p4 é o outro. Quando o dispositivo perde energia, o relé curto-circuita fisicamente cada par para que o tráfego continue passando pela caixa sem o WAF no caminho. Se esse curto-circuito realmente ajuda o seu tráfego depende inteiramente de em qual bond cada porta acabou.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A fiação errada (esquerda) não é um erro raro — é a mais intuitiva, porque agrupar s1p1+s1p2 em um mesmo bond parece organizado em um diagrama de cabeamento. Também é exatamente o que anula o bypass: o relé curto-circuita duas portas que pertencem ao mesmo bond, então o tráfego comutado volta para onde veio em vez de cruzar para o outro bond. A correção é cruzar a fiação para que cada bond contenha uma porta de cada par de bypass.
Duas coisas distintas precisam ser verdadeiras ao mesmo tempo: o cabeamento físico precisa cruzar os pares de bypass, e o LACP precisa realmente negociar — nenhuma das duas sozinha é suficiente.
Esta é a única decisão de cabeamento da qual todo o resto da implantação depende — acerte isso antes de configurar qualquer outra coisa.
Bridge: br0
bond1 members: s1p1, s1p3 // one port from each bypass pair
bond2 members: s1p2, s1p4 // the other port from each bypass pair
bypass pairs (fixed in hardware): s1p1<->s1p2 , s1p3<->s1p4
// bypass short on s1p1<->s1p2 now crosses bond1 -> bond2, matching the bridge directionO WAF só fala LACP dinâmico — confirme isso antes de gastar tempo comparando algoritmos de balanceamento de carga.
WAF supported aggregation modes:
LACP 802.3ad -- dynamic only, no static aggregation support
Load-balance Round-robin
Load-balance XOR
active-backup
Bridge build checklist:
[ ] Resolve LACPDU packets -- must be checked, or LACP frames are never read
[ ] Load-balancing algorithm: 2+3-layer or 3+4-layer -- match the peer's hash
// symptom: negotiation fails even after changing mode and algorithm repeatedly
// -> peer is very likely on STATIC aggregation, which WAF cannot negotiate againstDepois que o cabeamento e as configurações de LACP estão corretos, estas são as formas específicas como isso ainda dá errado em campo.
SINTOMAUm evento de bypass de hardware é disparado — perda de energia ou um teste deliberado — mas o tráfego de negócio ainda não flui, mesmo que o status de bypass mostre ativo.
CAUSAAs duas portas físicas de um mesmo par de relé de bypass (s1p1+s1p2, ou s1p3+s1p4) foram agregadas no mesmo bond lógico. Quando o relé curto-circuita esse par, o tráfego comutado volta para o bond de onde veio — nunca chega ao outro bond, então nunca atravessa a ponte.
SOLUÇÃOReconstrua os bonds para que cada um contenha exatamente uma porta de cada par de bypass: bond1 = s1p1 + s1p3, bond2 = s1p2 + s1p4.
// wrong
bond1: s1p1, s1p2 // both members of the same bypass relay pair
bond2: s1p3, s1p4
// correct
bond1: s1p1, s1p3 // one port from each bypass pair
bond2: s1p2, s1p4SINTOMAO modo de agregação e o algoritmo de balanceamento de carga foram alterados repetidamente do lado do WAF, e a negociação ainda falha.
CAUSAO switch par está configurado para um grupo de agregação estático/manual. A implementação 802.3ad do WAF só fala LACP dinâmico — não há modo de agregação estático de fallback, então nenhuma mudança de algoritmo do lado do WAF vai resolver isso.
SOLUÇÃOMude o switch par para LACP dinâmico (802.3ad) e confirme que o protocolo de negociação coincide antes de mexer no algoritmo.
SINTOMAAmbas as pontas configuradas explicitamente para 802.3ad, e a agregação ainda não negocia — ou negocia mas a distribuição de tráfego parece errada.
CAUSAO algoritmo de hash / distribuição difere entre as duas pontas — por exemplo o WAF configurado em 3+4 camadas contra um switch com hash em 2+3 camadas, ou o par que na verdade não está rodando 802.3ad apesar das aparências.
SOLUÇÃOSe o par estiver confirmado em 802.3ad, tente alternar o WAF entre 2+3 camadas e 3+4 camadas para encontrar a correspondência. Se o par não estiver explicitamente em 802.3ad, mude o próprio modo de agregação do WAF para Round-robin ou XOR.
SINTOMAAmbas as pontas parecem corretamente configuradas para 802.3ad com o mesmo algoritmo, e a agregação nunca se forma.
CAUSAA etapa de criação da ponte tem uma caixa de seleção separada para analisar pacotes LACPDU. Sem ela, o WAF nunca lê os quadros de controle LACP do par — do ponto de vista do WAF, não há conversa LACP alguma acontecendo, não importa quão correto esteja o resto da configuração.
SOLUÇÃOEdite a configuração da ponte e habilite analisar pacotes LACPDU, depois reverifique o status da negociação.
SINTOMATempo gasto construindo um plano de emergência de bypass para uma implantação que na verdade está em modo de monitoramento (fora do caminho).
CAUSANo modo de monitoramento, o WAF não está em linha com o tráfego de negócio de forma alguma — uma falha do dispositivo não tem efeito no caminho de passagem, e não há decisão de relé de bypass de hardware a tomar porque não há nada no caminho de tráfego para contornar.
SOLUÇÃOConfirme primeiro o modo de implantação — ponte transparente inline versus monitoramento fora do caminho — antes de gastar tempo em um plano de cabeamento de bypass; o modo de monitoramento não precisa de nada disso.
Tiradas de casos de campo — as que vale a pena ter uma resposta pronta.
O bypass de hardware é um relé físico embutido em pares de portas específicos para que, em uma implantação transparente inline, o tráfego continue fluindo diretamente através dessas duas portas mesmo que o WAF perca energia ou trave — sem envolvimento de software, puramente elétrico. Importa em qual bond lógico cada porta acaba, porque o relé só curto-circuita as duas portas físicas do seu próprio par; se a agregação de links já agrupou ambas as portas no mesmo bond, o curto-circuito roteia o tráfego de volta para aquele bond em vez de atravessar para o parceiro da ponte, e o tráfego de negócio permanece indisponível mesmo que o bypass tenha disparado corretamente.
Verifique a rotulagem do painel de hardware e a documentação de portas da plataforma antes de cabear — os pares de bypass são fixos por grupo de portas no dispositivo (por exemplo s1p1↔s1p2 e s1p3↔s1p4 nesta plataforma) e não mudam com a configuração. Confirmar isso antes de cabear é muito mais barato do que recabear depois de um teste de bypass falho.
Confirme que o switch par está em LACP dinâmico (802.3ad), não em um grupo de agregação estático — o WAF não tem fallback estático. Depois verifique se Resolver pacotes LACPDU está habilitado na ponte; sem isso o WAF nunca lê os quadros de controle do par. Só depois de confirmar os dois é que vale a pena comparar o algoritmo de balanceamento de carga (2+3 camadas vs 3+4 camadas) entre as duas pontas.
Não. O modo de monitoramento não coloca o WAF no caminho do tráfego de negócio de forma alguma, então uma falha do dispositivo não tem efeito no tráfego de passagem e não há decisão de relé de bypass de hardware a tomar. O cabeamento de agregação e bypass acima só importa para uma implantação de ponte transparente inline.
Quatro opções: LACP 802.3ad (negociação dinâmica com o par, a escolha usual quando o switch par suporta), balanceamento de carga Round-robin, balanceamento de carga XOR (hash baseado em política), e active-backup (uma porta ativa, uma em espera). Se o switch par executa explicitamente 802.3ad, alinhe-se a ele e ao algoritmo de hash; se não, Round-robin ou XOR evita uma negociação que nunca vai se completar.
Esta nota se baseia no pareamento de portas compatíveis com bypass de um appliance WAF Huawei (s1p1↔s1p2, s1p3↔s1p4), seus modos de agregação suportados, e os casos de campo por trás do conflito entre agregação e bypass. Se as portas compatíveis com bypass da sua plataforma forem numeradas ou agrupadas de forma diferente, os nomes exatos das interfaces mudam, mas a regra subjacente — agregar cruzando os pares de bypass, nunca dentro de um só — se aplica diretamente. Não cobre o comportamento de bypass em nível de software/aplicação, implantações não transparentes (proxy reverso) onde o bypass de hardware não se aplica da mesma forma, nem agregação com mais de dois pares de portas compatíveis com bypass.
Envie-nos a rotulagem dos pares de bypass do seu painel de hardware e como os bonds estão cabeados atualmente, e ajudaremos você a verificar se o cruzamento está correto antes de testar o failover em produção.