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 Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
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.
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.
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.
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.
A mesma sequência acima — aqui está o que acontece quando um portão é pulado, e o que verificar em vez disso.
RISCOA documentação original 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.
RISCOA documentação original é 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.
RISCOCE-LIC-LU controla esse recurso, e a documentação original 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.
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.
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.
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.
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Não — a documentação original é 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.
Não. A documentação original 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.
OSPF, OSPFv3, BGP ou BGP4+, segundo a documentação original. 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.
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.
Então esse sequenciamento não consegue proteger totalmente as atualizações de BorderLeaf em uma topologia quadrada (loop PE-BorderLeaf) — a documentação original 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.
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.
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 original, não como lacunas deste resumo.
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.