Atualização sem perda de um par M-LAG: um sequenciamento que mantém o tráfego fluindo
Atualizar um membro de M-LAG não precisa custar um único pacote — mas só se o tráfego sair antes de a atualização de software começar, e voltar somente depois de as tabelas terem ressincronizado. Esta é a sequência de custo de rota e queda do link descendente que desloca o tráfego para fora do membro em atualização, o portão de verificação em cada etapa, e o ponto de retrocesso caso a troca de tráfego nunca se complete.
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
O que “sem perda” realmente significa para uma atualização de M-LAG
A atualização sem perda de M-LAG não torna o switch em atualização invisível ao tráfego — ela primeiro move o tráfego para outro lugar, atualiza o assento vazio, e depois o traz de volta.
A atualização sem perda de M-LAG consiste em comutar o tráfego para o link de backup antes de o membro de M-LAG em atualização ficar fora de operação, de modo que o negócio não sinta a atualização de software. Em um par típico, Leaf1 e Leaf2 formam o M-LAG, ambos alcançam o restante da rede por um protocolo de roteamento dinâmico, e os servidores se conectam duplamente ao par. O sequenciamento ajusta o custo de rota e a prioridade de anúncio de Leaf1 e define sua interface descendente como Down, espera que o tráfego realmente se mova para Leaf2, atualiza Leaf1, e então reverte as três configurações assim que Leaf1 está saudável novamente — e repete a mesma sequência para Leaf2.
Nada disso funciona se o par não estiver saudável para começar. Antes de agendar esta atualização, confirme o estado do peer-link e o pareamento DFS do M-LAG da mesma forma que faria ao diagnosticar uma falha de M-LAG — a ordem de diagnóstico da nossa nota de solução de problemas de M-LAG vale a pena ser executada como um portão pré-atualização, não apenas pós-falha.
A troca de tráfego em quatro fases
Cada fase existe para garantir que o tráfego só se mova quando estiver confirmado que há um lugar seguro para onde ir — e só retorne quando o membro para o qual está voltando estiver confirmado saudável.
Os rótulos do diagrama são mantidos em inglês para clareza técnica.
Os templates chamados UpLinkSwitch, DownLinkSwitch, DownLinkSwitchDelete e UpLinkSwitchDelete são o que realmente executa cada metade dessa troca — aplicá-los e removê-los na ordem errada é o que transforma essa atualização sem perda em uma com perda.
Pré-requisitos e restrições
Seis condições, diretamente do procedimento original — a License, a dupla conexão, os protocolos suportados, e os dois padrões de tráfego que esta sequência não consegue proteger totalmente.
| Requisito | Detalhe | Por que importa |
|---|---|---|
| License | CE-LIC-LU deve estar carregado e habilitado; vem desativado por padrão em equipamentos novos. | Sem ele, o próprio recurso de atualização sem perda não está disponível, não importa quão cuidadosamente a sequência abaixo seja seguida. |
| Conexão dupla | Servidores, firewalls e balanceadores de carga devem se conectar duplamente ao grupo M-LAG via LACP, com as NICs dos servidores em bond mode4. | Qualquer dispositivo downstream com conexão única não tem para onde deslocar seu tráfego quando seu membro fica fora de operação para atualização. |
| Protocolo de roteamento | OSPF, OSPFv3, BGP ou BGP4+. | Outros protocolos não são cobertos pelo mecanismo de custo de rota e prioridade de anúncio do qual esta sequência depende. |
| Multicast | Não suportado. | O tráfego multicast não segue a mesma comutação orientada por custo de rota e será perdido independentemente de quão bem o resto da sequência seja executado. |
| Tráfego leste-oeste | O tráfego L2/L3 entre servidores sob o mesmo grupo M-LAG não consegue atingir 0 perda de pacotes durante a troca. | Estabeleça expectativas antes da janela de manutenção: “sem perda” descreve o caminho roteado norte-sul, não esse padrão leste-oeste específico. |
| Link de escape PE / BorderLeaf | Quando PE e BorderLeaf se conectam em uma topologia quadrada, um link de escape entre os grupos PE é obrigatório. | Sem ele, um BorderLeaf em atualização não tem para onde enviar seu tráfego, e este sequenciamento não tem para onde comutar. |
Fonte: documentação de manutenção da solução de rede de data center de IA, procedimento de atualização sem perda M-LAG do switch.
Templates usados nesta sequência
Quatro templates entregues pelo controlador, aplicados via Gestão de Elementos de Rede > Programação Específica do Dispositivo, fazem o trabalho real de deslocar e restaurar o tráfego.
| Template | Aplicado a | Efeito |
|---|---|---|
| UpLinkSwitch | Leaf sendo retirado para atualização | Ajusta o custo de rota e a prioridade de anúncio de rota para que o tráfego upstream prefira o par. |
| DownLinkSwitch | Mesmo Leaf, após confirmação da convergência de rota | Define como Down a porta membro Eth-Trunk descendente vinculada ao M-LAG. |
| DownLinkSwitchDelete | Mesmo Leaf, após a atualização | Restaura para Up a porta membro Eth-Trunk descendente, uma vez que as entradas ARP/ND/MAC da porta membro M-LAG tenham ressincronizado. |
| UpLinkSwitchDelete | Mesmo Leaf, após a atualização | Restaura o custo de rota e a prioridade de anúncio, comutando o tráfego roteado de volta para este Leaf. |
<HUAWEI> display ip routing-table vpn-instance vpn-name
Route Flags: R - relay, D - download to fib, T - to vpn-instance
Destination/Mask Proto Pre Cost Flags NextHop Interface
<HUAWEI> display interface brief
PHY: Physical
*down: administratively down
Interface PHY Protocol InUti OutUti inErrors outErrors
<HUAWEI> display ip routing-table vpn-instance vpn-name
<HUAWEI> display interface briefFonte: documentação de manutenção da solução de rede de data center de IA — os mesmos dois comandos verificam tanto a troca de saída quanto a de retorno.
5 armadilhas: onde uma atualização sem perda se torna uma com perda
A mesma sequência acima — aqui está o que acontece quando um portão é pulado, e o que verificar em vez disso.
1. O tráfego multicast não tem a garantia sem perda, não importa o que mais você faça certo
RISCOA documentação do fabricante exclui completamente os serviços de multicast deste mecanismo — o multicast não segue a comutação por custo de rota e prioridade de anúncio, então ele se perde quando o membro fica fora de operação, independentemente de quão cuidadosamente o resto da sequência seja executado.
PRÁTICA MAIS SEGURAIdentifique quaisquer serviços de multicast que circulem sobre este par M-LAG antes de agendar a janela, e estabeleça expectativas separadas para eles — esta sequência protege o caminho unicast roteado, não o multicast.
2. O tráfego leste-oeste entre servidores do mesmo grupo M-LAG não pode ser totalmente sem perda
RISCOA documentação do fabricante é explícita: o tráfego L2/L3 leste-oeste entre servidores com dupla conexão ao mesmo grupo M-LAG não consegue atingir 0 perda de pacotes durante a comutação, não importa quão corretamente a sequência seja executada.
PRÁTICA MAIS SEGURAComunique essa limitação aos responsáveis pelas aplicações antes da janela — “sem perda” neste contexto significa o tráfego norte-sul roteado, e os fluxos leste-oeste entre servidores colocalizados são o único padrão que este sequenciamento nunca pretendeu cobrir totalmente.
3. A License de atualização sem perda vem desativada por padrão — descobrir isso no meio da janela é tarde demais
RISCOCE-LIC-LU controla esse recurso, e a documentação do fabricante observa que ele não vem habilitado por padrão em equipamentos recém-adquiridos mesmo quando o hardware o suporta — tentar a sequência sem ele significa que os templates não estão disponíveis ou não se comportam como esperado.
PRÁTICA MAIS SEGURAConfirme que o CE-LIC-LU está carregado e habilitado em ambos os equipamentos Leaf enquanto você ainda está montando o plano de manutenção, não com a janela já aberta.
4. Colocar o link descendente em Down antes de confirmar a convergência de rota causa exatamente a perda que você está evitando
RISCOA sequência aplica primeiro o UpLinkSwitch, depois espera a confirmação da convergência de rota, e só então aplica o DownLinkSwitch. Inverter essa ordem — ou pular a espera — coloca o link descendente em Down enquanto o tráfego ainda está sendo roteado pelo Leaf prestes a ser atualizado.
PRÁTICA MAIS SEGURATrate as verificações da tabela de roteamento e da interface após o UpLinkSwitch como um portão rígido, não uma formalidade — não aplique o DownLinkSwitch até que o display ip routing-table confirme a convergência e o tráfego realmente tenha se movido.
5. Restaurar o link descendente antes de as entradas ARP/ND/MAC ressincronizarem perde tráfego no retorno
RISCOO DownLinkSwitchDelete traz o link descendente de volta para Up, mas se a comutação de retorno do tráfego roteado ocorrer antes de as entradas ARP, ND e MAC da porta membro M-LAG terem ressincronizado, o caminho de retorno carrega estado de encaminhamento obsoleto e perde pacotes.
PRÁTICA MAIS SEGURAApós restaurar a interface para Up, verifique se as entradas sincronizadas se recuperaram antes de aplicar o UpLinkSwitchDelete — a ressincronização das entradas é o portão para o retorno da rota, não o contrário.
A sequência de atualização, passo a passo, com pontos de retrocesso
Confirme que o CE-LIC-LU está habilitado e que o peer-link do par M-LAG está saudável antes de começar — se um firewall ou balanceador de carga com dupla conexão reside neste mesmo par, seu próprio sequenciamento de atualização segue uma disciplina similar de isolar-verificar-comutar, que vale a pena verificar cruzadamente com nossa nota de manutenção de atualização de firewall se ambos os equipamentos estiverem previstos na mesma janela.
- No aplicativo Southbound Open Services, selecione Gestão de Elementos de Rede > Programação Específica do Dispositivo, selecione Leaf1, e aplique o template UpLinkSwitch — isso ajusta o custo de rota e a prioridade de anúncio de rota.
- Envie e entregue o template, depois faça login no Leaf1 e execute display ip routing-table [ vpn-instance vpn-name ] para confirmar que a rota convergiu e o tráfego está se deslocando para o Leaf2. Não prossiga até confirmar isso — este é o primeiro ponto de retrocesso: se a convergência nunca se completar, desfaça o UpLinkSwitch e investigue antes de mexer no link descendente.
- Uma vez confirmada a convergência, aplique o template DownLinkSwitch no Leaf1, colocando a porta membro Eth-Trunk descendente em Down.
- Execute display interface brief para confirmar que o tráfego realmente se deslocou para o Leaf2 antes de continuar.
- Atualize a versão de software do Leaf1, seguindo o guia de atualização próprio do produto ou a atualização assistida do controlador.
- Após a conclusão da atualização, verifique se os vizinhos de roteamento estão estabelecidos, se o túnel VXLAN está Up, e se as entradas da tabela MAC e de rota do lado do túnel estão normais antes de continuar — este é o segundo ponto de retrocesso: não restaure o tráfego para um Leaf que não passou nessa verificação de saúde.
- Aplique o template DownLinkSwitchDelete no Leaf1 para restaurar a porta membro Eth-Trunk descendente para Up.
- Verifique se as entradas ARP, ND e MAC da porta membro M-LAG ressincronizaram antes de fazer qualquer outra coisa — este é o terceiro ponto de retrocesso: pare aqui se as entradas não tiverem se recuperado.
- Aplique o template UpLinkSwitchDelete no Leaf1 para restaurar o custo de rota e a prioridade de anúncio, comutando o tráfego roteado de volta.
- Execute display ip routing-table [ vpn-instance vpn-name ] e display interface brief para confirmar a convergência de rota e que o tráfego realmente retornou ao Leaf1.
- Repita os passos 1 a 10 para o Leaf2, usando o Leaf1 como destino do tráfego durante a janela de atualização do Leaf2.
- Uma vez que ambos os equipamentos Leaf estejam atualizados e o tráfego volte a ser distribuído normalmente entre o par, a atualização do grupo M-LAG está completa.
Projetos de soluções relacionadas
Seis perguntas que surgem constantemente
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
“Sem perda” realmente significa 0 pacotes perdidos para absolutamente tudo?
Não — a documentação do fabricante é explícita ao afirmar que o tráfego L2/L3 leste-oeste entre servidores com dupla conexão ao mesmo grupo M-LAG não consegue atingir 0 perda de pacotes durante a comutação. “Sem perda” descreve o tráfego norte-sul roteado que os templates de custo de rota, prioridade de anúncio e queda do link descendente redirecionam antes de o membro em atualização ficar fora de operação.
Este procedimento funciona para tráfego multicast?
Não. A documentação do fabricante exclui explicitamente os serviços de multicast do suporte à atualização sem perda — planeje que o tráfego multicast será afetado independentemente de quão cuidadosamente esta sequência seja seguida.
Em quais protocolos de roteamento este sequenciamento se baseia?
OSPF, OSPFv3, BGP ou BGP4+, segundo a documentação do fabricante. Outros protocolos de roteamento não são cobertos pelo mecanismo de custo de rota e prioridade de anúncio do qual esta sequência depende.
Preciso de uma License especial para isso?
Sim — CE-LIC-LU, o item de controle de License de atualização sem perda de M-LAG. Vem desativado por padrão em equipamentos recém-adquiridos, mesmo quando o hardware suporta tecnicamente o recurso, então confirme que está carregado antes de agendar a janela.
E se eu tiver apenas um par PE/BorderLeaf sem link de escape?
Então esse sequenciamento não consegue proteger totalmente as atualizações de BorderLeaf em uma topologia quadrada (loop PE-BorderLeaf) — a documentação do fabricante exige um link de escape entre os grupos PE especificamente para que o tráfego tenha para onde ir enquanto um BorderLeaf está sendo atualizado.
Posso pular direto para atualizar o Leaf1 sem aplicar antes os templates UpLinkSwitch e DownLinkSwitch?
Não — pular os templates do lado da rota e de queda de interface, ou não esperar a verificação de convergência entre eles, significa que o Leaf1 fica fora de operação para atualização enquanto ainda carrega tráfego ao vivo, produzindo exatamente a perda que este sequenciamento existe para evitar.
Limites honestos desta nota
Esta nota segue o procedimento de atualização sem perda M-LAG do switch da documentação de manutenção da solução de rede de data center de IA, orquestrado através dos templates Southbound Open Services do iMaster NCE-Fabric mostrados aqui. Ela assume OSPF, OSPFv3, BGP ou BGP4+ como protocolo de roteamento, e explicitamente não cobre tráfego multicast nem faz qualquer afirmação de sem perda para tráfego leste-oeste entre servidores no mesmo grupo M-LAG — ambos são apontados como exceções na própria documentação do fabricante, não como lacunas deste resumo.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
Não tem certeza se o seu par M-LAG realmente está pronto para isso?
Envie-nos o estado do peer-link e do pareamento DFS, se o CE-LIC-LU está carregado, e qual protocolo de roteamento você está usando, e ajudaremos você a confirmar que esta sequência vai se sustentar antes de agendar a janela.