Actualización sin pérdida de un par M-LAG: una secuenciación que mantiene el tráfico fluyendo
Actualizar un miembro de M-LAG no tiene por qué costar un solo paquete — pero solo si el tráfico se retira antes de que empiece la actualización de software, y regresa solo después de que las tablas se hayan resincronizado. Esta es la secuencia de coste de ruta y bajada del enlace descendente que traslada el tráfico fuera del miembro que se está actualizando, la puerta de verificación en cada etapa, y el punto de retroceso si el cambio de tráfico nunca llega a completarse.
Por Atlas Yuwen Zhang, fundador de AtlasCommTech — 18 años en ICT, 13 de ellos en redes de operador · Actualizado en julio de 2026
Qué significa realmente “sin pérdida” para una actualización de M-LAG
La actualización sin pérdida de M-LAG no hace invisible al tráfico el switch que se está actualizando — primero traslada el tráfico a otro lugar, actualiza el asiento vacío, y luego lo devuelve.
La actualización sin pérdida de M-LAG consiste en conmutar el tráfico al enlace de respaldo antes de que el miembro de M-LAG que se va a actualizar quede fuera de servicio, de modo que el negocio no note en absoluto la actualización de software. En un par típico, Leaf1 y Leaf2 forman el M-LAG, ambos llegan al resto de la red mediante un protocolo de enrutamiento dinámico, y los servidores se conectan doblemente al par. La secuenciación ajusta el coste de ruta y la prioridad de anuncio de Leaf1 y pone su interfaz descendente en Down, espera a que el tráfico realmente se traslade a Leaf2, actualiza Leaf1, y luego revierte los tres ajustes una vez que Leaf1 vuelve a estar sano — y repite la misma secuencia para Leaf2.
Nada de esto funciona si el par no está sano desde el principio. Antes de programar esta actualización, confirme el estado del peer-link y el emparejamiento DFS del M-LAG de la misma manera que lo haría al diagnosticar una falla de M-LAG — el orden de diagnóstico de nuestra nota de resolución de problemas de M-LAG merece ejecutarse como una puerta previa a la actualización, no solo tras un fallo.
El cambio de tráfico en cuatro fases
Cada fase existe para asegurar que el tráfico solo se mueva cuando se confirma que tiene un lugar seguro adónde ir — y solo regrese cuando el miembro al que vuelve se confirma sano.
Las etiquetas del diagrama se mantienen en inglés para mayor claridad técnica.
Las plantillas llamadas UpLinkSwitch, DownLinkSwitch, DownLinkSwitchDelete y UpLinkSwitchDelete son las que realmente ejecutan cada mitad de este cambio — aplicarlas y retirarlas en el orden equivocado es lo que convierte esta actualización sin pérdida en una con pérdida.
Requisitos previos y restricciones
Seis condiciones, directamente del procedimiento original — la License, la doble conexión, los protocolos admitidos, y los dos patrones de tráfico que esta secuencia no puede proteger por completo.
| Requisito | Detalle | Por qué importa |
|---|---|---|
| License | Se debe cargar y habilitar CE-LIC-LU; viene desactivado por defecto en equipos nuevos. | Sin él, la propia función de actualización sin pérdida no está disponible, sin importar con qué cuidado se siga la secuencia siguiente. |
| Conexión dual | Los servidores, firewalls y balanceadores de carga deben conectarse doblemente al grupo M-LAG mediante LACP, con las NIC de los servidores en bond mode4. | Cualquier dispositivo aguas abajo con conexión única no tiene adónde trasladar su tráfico cuando su miembro queda fuera de servicio para la actualización. |
| Protocolo de enrutamiento | OSPF, OSPFv3, BGP o BGP4+. | Otros protocolos no están cubiertos por el mecanismo de coste de ruta y prioridad de anuncio del que depende esta secuencia. |
| Multidifusión | No compatible. | El tráfico de multidifusión no sigue el mismo cambio impulsado por el coste de ruta y se perderá sin importar qué tan bien se ejecute el resto de la secuencia. |
| Tráfico este-oeste | El tráfico L2/L3 entre servidores bajo el mismo grupo M-LAG no puede alcanzar 0 pérdida de paquetes durante el cambio. | Establezca expectativas antes de la ventana de mantenimiento: “sin pérdida” describe la ruta enrutada norte-sur, no este patrón este-oeste específico. |
| Enlace de escape PE / BorderLeaf | Cuando PE y BorderLeaf se conectan en una topología cuadrada, un enlace de escape entre los grupos PE es obligatorio. | Sin él, un BorderLeaf que se está actualizando no tiene adónde enviar su tráfico, y esta secuenciación no tiene nada hacia lo cual conmutar. |
Fuente: documentación de mantenimiento de la solución de red de centro de datos de IA, procedimiento de actualización sin pérdida M-LAG del switch.
Plantillas usadas en esta secuencia
Cuatro plantillas entregadas por el controlador, aplicadas mediante Gestión de elementos de red > Programación específica del dispositivo, realizan el trabajo real de desplazar y restaurar el tráfico.
| Plantilla | Aplicado a | Efecto |
|---|---|---|
| UpLinkSwitch | Leaf que se retira para la actualización | Ajusta el coste de ruta y la prioridad de anuncio de ruta para que el tráfico ascendente prefiera al par. |
| DownLinkSwitch | Mismo Leaf, tras confirmar la convergencia de ruta | Pone en Down el puerto miembro Eth-Trunk descendente unido al M-LAG. |
| DownLinkSwitchDelete | Mismo Leaf, tras la actualización | Restaura a Up el puerto miembro Eth-Trunk descendente, una vez que las entradas ARP/ND/MAC del puerto miembro M-LAG se han resincronizado. |
| UpLinkSwitchDelete | Mismo Leaf, tras la actualización | Restaura el coste de ruta y la prioridad de anuncio, devolviendo el tráfico enrutado a 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 briefFuente: documentación de mantenimiento de la solución de red de centro de datos de IA — los mismos dos comandos verifican tanto el cambio de salida como el de regreso.
5 trampas: dónde una actualización sin pérdida se convierte en una con pérdida
La misma secuencia de arriba — esto es lo que pasa cuando se salta una puerta, y qué comprobar en su lugar.
1. El tráfico de multidifusión no tiene la garantía sin pérdida, hagas lo que hagas bien en lo demás
RIESGOLa documentación del fabricante excluye por completo los servicios de multidifusión de este mecanismo — la multidifusión no sigue el cambio por coste de ruta y prioridad de anuncio, así que se pierde cuando el miembro queda fuera de servicio, sin importar con qué cuidado se ejecute el resto de la secuencia.
PRÁCTICA MÁS SEGURAIdentifique cualquier servicio de multidifusión que circule sobre este par M-LAG antes de programar la ventana, y establezca expectativas separadas para ellos — esta secuencia protege la ruta unicast enrutada, no la multidifusión.
2. El tráfico este-oeste entre servidores del mismo grupo M-LAG no puede ser completamente sin pérdida
RIESGOLa documentación del fabricante es explícita: el tráfico L2/L3 este-oeste entre servidores con doble conexión al mismo grupo M-LAG no puede alcanzar 0 pérdida de paquetes durante la conmutación, sin importar cuán correctamente se ejecute la secuencia.
PRÁCTICA MÁS SEGURAComunique esta limitación a los responsables de las aplicaciones antes de la ventana — “sin pérdida” en este contexto significa el tráfico norte-sur enrutado, y los flujos este-oeste entre servidores colocados juntos son el único patrón que esta secuenciación nunca pretendió cubrir por completo.
3. La License de actualización sin pérdida está desactivada por defecto — descubrirlo a mitad de la ventana es demasiado tarde
RIESGOCE-LIC-LU controla esta función, y la documentación del fabricante señala que no está habilitada por defecto en equipos recién adquiridos incluso cuando el hardware la admite — intentar la secuencia sin ella significa que las plantillas no están disponibles o no se comportan como se espera.
PRÁCTICA MÁS SEGURAConfirme que CE-LIC-LU está cargado y habilitado en ambos equipos Leaf mientras todavía está elaborando el plan de mantenimiento, no cuando la ventana ya esté abierta.
4. Poner el enlace descendente en Down antes de confirmar la convergencia de ruta causa exactamente la pérdida que se está evitando
RIESGOLa secuencia aplica primero UpLinkSwitch, luego espera la confirmación de la convergencia de ruta, y solo entonces aplica DownLinkSwitch. Invertir ese orden — u omitir la espera — pone el enlace descendente en Down mientras el tráfico todavía se enruta a través del Leaf a punto de actualizarse.
PRÁCTICA MÁS SEGURATrate las comprobaciones de la tabla de enrutamiento y la interfaz después de UpLinkSwitch como una puerta estricta, no un trámite — no aplique DownLinkSwitch hasta que display ip routing-table confirme la convergencia y el tráfico realmente se haya movido.
5. Restaurar el enlace descendente antes de que las entradas ARP/ND/MAC se resincronicen pierde tráfico en el regreso
RIESGODownLinkSwitchDelete devuelve el enlace descendente a Up, pero si el retorno del tráfico enrutado ocurre antes de que las entradas ARP, ND y MAC del puerto miembro M-LAG se hayan resincronizado, la ruta de regreso lleva un estado de reenvío obsoleto y pierde paquetes.
PRÁCTICA MÁS SEGURADespués de restaurar la interfaz a Up, verifique que las entradas sincronizadas se hayan recuperado antes de aplicar UpLinkSwitchDelete — la resincronización de entradas es la puerta para el retorno de ruta, no al revés.
La secuencia de actualización, paso a paso, con puntos de retroceso
Confirme que CE-LIC-LU está habilitado y que el peer-link del par M-LAG está sano antes de empezar — si un firewall o balanceador de carga con doble conexión reside en este mismo par, su propia secuenciación de actualización sigue una disciplina similar de aislar-verificar-conmutar, que vale la pena contrastar con nuestra nota de mantenimiento de actualización de firewall si ambos equipos están previstos en la misma ventana.
- En la aplicación Southbound Open Services, seleccione Gestión de elementos de red > Programación específica del dispositivo, seleccione Leaf1, y aplique la plantilla UpLinkSwitch — esto ajusta el coste de ruta y la prioridad de anuncio de ruta.
- Envíe y entregue la plantilla, luego inicie sesión en Leaf1 y ejecute display ip routing-table [ vpn-instance vpn-name ] para confirmar que la ruta ha convergido y el tráfico se está desplazando hacia Leaf2. No continúe hasta confirmarlo — este es el primer punto de retroceso: si la convergencia nunca se completa, deshaga UpLinkSwitch e investigue antes de tocar el enlace descendente.
- Una vez confirmada la convergencia, aplique la plantilla DownLinkSwitch en Leaf1, poniendo en Down el puerto miembro Eth-Trunk descendente.
- Ejecute display interface brief para confirmar que el tráfico realmente se ha trasladado a Leaf2 antes de continuar.
- Actualice la versión de software de Leaf1, siguiendo la guía de actualización propia del producto o la actualización asistida del controlador.
- Después de completar la actualización, compruebe que los vecinos de enrutamiento estén establecidos, que el túnel VXLAN esté Up, y que las entradas de la tabla MAC y de ruta del lado del túnel sean normales antes de continuar — este es el segundo punto de retroceso: no restaure el tráfico a un Leaf que no haya pasado esta verificación de estado.
- Aplique la plantilla DownLinkSwitchDelete en Leaf1 para restaurar a Up el puerto miembro Eth-Trunk descendente.
- Verifique que las entradas ARP, ND y MAC del puerto miembro M-LAG se hayan resincronizado antes de hacer cualquier otra cosa — este es el tercer punto de retroceso: deténgase aquí si las entradas no se han recuperado.
- Aplique la plantilla UpLinkSwitchDelete en Leaf1 para restaurar el coste de ruta y la prioridad de anuncio, devolviendo el tráfico enrutado.
- Ejecute display ip routing-table [ vpn-instance vpn-name ] y display interface brief para confirmar la convergencia de ruta y que el tráfico realmente ha regresado a Leaf1.
- Repita los pasos 1 a 10 para Leaf2, usando Leaf1 como destino del tráfico durante la ventana de actualización de Leaf2.
- Una vez que ambos equipos Leaf están actualizados y el tráfico vuelve a repartirse normalmente entre el par, la actualización del grupo M-LAG está completa.
Diseños de soluciones relacionadas
Seis preguntas que surgen constantemente
Sacadas directamente del terreno — las que vale la pena tener respondidas de antemano.
¿“Sin pérdida” significa realmente 0 paquetes perdidos para absolutamente todo?
No — la documentación del fabricante es explícita en que el tráfico L2/L3 este-oeste entre servidores con doble conexión al mismo grupo M-LAG no puede alcanzar 0 pérdida de paquetes durante la conmutación. “Sin pérdida” describe el tráfico norte-sur enrutado que las plantillas de coste de ruta, prioridad de anuncio y bajada del enlace descendente redirigen antes de que el miembro que se está actualizando quede fuera de servicio.
¿Este procedimiento funciona para el tráfico de multidifusión?
No. La documentación del fabricante excluye explícitamente los servicios de multidifusión del soporte de actualización sin pérdida — prevea que el tráfico de multidifusión se verá afectado sin importar con qué cuidado se siga esta secuencia.
¿En qué protocolos de enrutamiento se basa esta secuenciación?
OSPF, OSPFv3, BGP o BGP4+, según la documentación del fabricante. Otros protocolos de enrutamiento no están cubiertos por el mecanismo de coste de ruta y prioridad de anuncio del que depende esta secuencia.
¿Necesito una License especial para esto?
Sí — CE-LIC-LU, el elemento de control de License de actualización sin pérdida de M-LAG. Está desactivado por defecto en equipos recién adquiridos, incluso cuando el hardware admite técnicamente la función, así que confirme que está cargado antes de programar la ventana.
¿Qué pasa si solo tengo un par PE/BorderLeaf sin enlace de escape?
Entonces esta secuenciación no puede proteger completamente las actualizaciones de BorderLeaf en una topología cuadrada (bucle PE-BorderLeaf) — la documentación del fabricante exige un enlace de escape entre los grupos PE precisamente para que el tráfico tenga adónde ir mientras se actualiza un BorderLeaf.
¿Puedo saltar directamente a actualizar Leaf1 sin aplicar antes las plantillas UpLinkSwitch y DownLinkSwitch?
No — saltarse las plantillas del lado de ruta y de bajada de interfaz, o no esperar la comprobación de convergencia entre ellas, significa que Leaf1 queda fuera de servicio para la actualización mientras aún transporta tráfico en vivo, produciendo exactamente la pérdida que esta secuenciación existe para evitar.
Límites honestos de esta nota
Esta nota sigue el procedimiento de actualización sin pérdida M-LAG del switch de la documentación de mantenimiento de la solución de red de centro de datos de IA, orquestado a través de las plantillas Southbound Open Services de iMaster NCE-Fabric mostradas aquí. Asume OSPF, OSPFv3, BGP o BGP4+ como protocolo de enrutamiento, y explícitamente no cubre el tráfico de multidifusión ni hace ninguna afirmación de sin pérdida para el tráfico este-oeste entre servidores del mismo grupo M-LAG — ambos se señalan como excepciones en la propia documentación del fabricante, no como vacíos de este resumen.
Referencias
Normas y documentos del fabricante en los que se basa esta nota. La sintaxis de comandos sigue la documentación del fabricante; verifique el comportamiento exacto en su versión de firmware.
¿No está seguro de que su par M-LAG esté realmente listo para esto?
Envíenos el estado del peer-link y el emparejamiento DFS, si CE-LIC-LU está cargado, y qué protocolo de enrutamiento está usando, y le ayudaremos a confirmar que esta secuencia se sostendrá antes de programar la ventana.