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 Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
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.
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.
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.
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.
La misma secuencia de arriba — esto es lo que pasa cuando se salta una puerta, y qué comprobar en su lugar.
RIESGOLa documentación original 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.
RIESGOLa documentación original 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.
RIESGOCE-LIC-LU controla esta función, y la documentación original 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.
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.
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.
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.
Sacadas directamente del terreno — las que vale la pena tener respondidas de antemano.
No — la documentación original 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.
No. La documentación original 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.
OSPF, OSPFv3, BGP o BGP4+, según la documentación original. Otros protocolos de enrutamiento no están cubiertos por el mecanismo de coste de ruta y prioridad de anuncio del que depende esta secuencia.
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.
Entonces esta secuenciación no puede proteger completamente las actualizaciones de BorderLeaf en una topología cuadrada (bucle PE-BorderLeaf) — la documentación original exige un enlace de escape entre los grupos PE precisamente para que el tráfico tenga adónde ir mientras se actualiza un BorderLeaf.
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.
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 original, no como vacíos de este resumen.
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.