Resumen

  • La corrección de una asignación duplicada y la liberación del estado de red pueden terminar en momentos distintos, aunque las ejecute la misma persona.
  • Un conflicto de MAC, uno de IP entre MAC diferentes y un entorno que solo anuncia rutas IP requieren identificar objetos de recuperación distintos.
  • Las especificaciones contemplan la liberación por temporizador de determinados estados. La decisión consiste en conocer su alcance y el riesgo restante, no en exigir siempre una operación manual.

La incidencia puede tener una tarea cerrada y un servicio todavía interrumpido. Esa diferencia no demuestra que alguien haya registrado un éxito falso. A veces revela que la organización dividió correctamente el trabajo, pero no asignó quién debía seguir el resultado entre las divisiones.

Considérese un caso hipotético, no una avería documentada. El equipo de plataforma descubre una máquina virtual que utiliza una dirección ya asignada y retira la instancia no deseada. Confirma que la configuración del equipo ha sido corregida. Sin embargo, en la red permanece una ruta congelada a raíz del conflicto. La primera intervención ha resuelto algo real, pero queda otro estado por recuperar.

Ese intervalo merece atención propia. No es necesariamente tiempo perdido: puede corresponder a una espera deliberada y conocida. También puede ser el tiempo que tarda una petición en encontrar a la persona con permisos, contexto o responsabilidad. Mezclarlo con el diagnóstico inicial impide saber qué capacidad falta.

Tampoco es obligatorio que intervengan dos departamentos. Una sola persona puede administrar ambos sistemas. Aun así, modificar la asignación de un extremo y liberar el estado que la red conserva son acciones distintas. Tener dos consolas disponibles no convierte una operación en la otra.

Por qué se mantiene una restricción

EVPN distribuye información de alcance de los extremos entre equipos de borde, denominados PE. Cuando un extremo cambia de segmento Ethernet, pueden coincidir anuncios de su ubicación anterior y de la nueva. El procedimiento de movilidad MAC descrito en RFC 7432 emplea números de secuencia para ordenar esos cambios y provocar la retirada de anuncios antiguos.

Dos equipos configurados con la misma MAC en el dominio de difusión pertinente pueden producir otra situación: sus transmisiones hacen que la dirección parezca cambiar de ubicación repetidamente. La especificación describe la detección mediante un número de movimientos dentro de una ventana temporal, con parámetros configurables. Al detectar la duplicación, el PE debe avisar al operador y detener el envío y tratamiento de anuncios MAC/IP para esa MAC hasta que se adopte una medida correctora.

Es una actuación sobre una dirección, no una orden de apagar toda la red. Otros PE todavía pueden enviar tráfico hacia uno de los equipos que anuncian la MAC afectada. La presencia de una alerta no informa por sí sola de lo que hace cada camino de reenvío.

También sería incorrecto contar varias ubicaciones sin distinguir su relación. Un extremo conectado de forma redundante a varios PE del mismo segmento no equivale a una MAC que se desplaza entre segmentos. El identificador de segmento ayuda precisamente a evitar falsas detecciones de movimiento en esa conexión múltiple. La redundancia prevista no debe transformarse, por una lectura superficial, en una avería imaginaria.

La congelación puede ser, por tanto, el resultado intencionado de una protección. No es necesariamente una entrada olvidada que deba borrarse cuanto antes. Mantenerla tras la corrección y liberarla mientras el conflicto persiste generan exposiciones diferentes. La ausencia de alarmas en una pantalla no resuelve esa elección.

El objeto del conflicto determina qué se corrige

RFC 9721 amplía los procedimientos de movilidad de EVPN con encaminamiento y puenteo integrados. Trata cambios que van más allá de trasladar una pareja IP-MAC intacta: una IP puede conservarse mientras pasa a otra MAC al recrear una carga de trabajo. También existen situaciones legítimas en las que varias IP comparten una MAC detrás de un sistema físico o de un equipo intermedio.

Compartir una MAC no constituye, por sí mismo, una duplicación accidental. Esa distinción importa al decidir qué corregir y qué servicio mantener.

El documento diferencia equipos con la misma MAC, equipos con la misma IP pero MAC distintas y una red puramente encaminada en la que no se anuncian las MAC de los extremos. Si la MAC se marca como duplicada, las rutas MAC-IP asociadas heredan esa condición. Cuando la duplicación corresponde a una IP entre MAC diferentes, se afecta a la ruta MAC-IP correspondiente sin convertir, solo por ese conflicto, en duplicadas la ruta MAC y todas las demás IP relacionadas con ella.

La orden de intervención debe conservar ese contexto. «Limpiar el equipo» no dice todavía qué asociación debe permanecer, dónde reside ni qué instancia presta el servicio previsto. Hace falta conectar la observación de la red con la configuración que la organización pretende mantener.

El lugar donde aparece el estado congelado tampoco decide cuál de los extremos debe desaparecer. RFC 9721 contempla la recuperación tras retirar la asignación duplicada tanto en el lado congelado como en el que no lo está. El indicador de la red no sustituye al conocimiento de la plataforma sobre cuál es la instancia correcta.

La corrección inicia otra parte de la recuperación

La sección 8.4 de RFC 9721 sitúa explícitamente la retirada de una de las asignaciones MAC o IP en conflicto en el lado del equipo. Después de esa corrección, todavía puede ser necesario esperar a que caduque el estado de duplicación, salvo que una actuación adicional acelere la recuperación.

El documento distingue entonces entre descongelar una ruta y eliminar una entrada. La descongelación puede producir un anuncio con un número de secuencia superior al de la otra ubicación. Los anuncios y los sondeos ARP o de descubrimiento de vecinos permiten reconciliar el alcance y eliminar estado local obsoleto. El desarrollo depende de dónde se haya retirado el extremo duplicado.

Borrar una ruta MAC local, o una entrada ARP o de vecinos, no equivale necesariamente a esa descongelación. En particular, limpiar estado en el lado no congelado puede dejar pendiente una liberación en otro lugar. Un comando puede terminar correctamente su trabajo local y, aun así, no completar la vuelta del servicio.

El requisito organizativo no es memorizar una orden universal para todos los fabricantes. Es conservar una explicación continua: qué asignación se corrigió, dónde, qué extremo debe seguir activo y qué estado de red todavía espera una actuación o un temporizador. La entrega entre responsables puede ser breve, pero «corregido» no siempre contiene información suficiente.

Hay además una diferencia entre retirar una instancia y evitar que vuelva. Supóngase, como ejemplo analítico, que la configuración deseada de un sistema de orquestación sigue pidiendo la instancia eliminada. El sistema podría recrearla. No se afirma aquí un comportamiento observado en un producto concreto. El ejemplo muestra por qué la autoridad sobre el objeto presente puede ser distinta de la autoridad sobre la configuración que lo reproduce.

En ese caso hipotético, acelerar la liberación de la red sin comprobar la persistencia de la corrección puede acortar el camino hacia otra disputa por la dirección. El responsable de recuperación necesita poder llegar al origen de la asignación, no limitarse a encontrar a alguien capaz de borrar una entrada visible.

Un temporizador también es una decisión de servicio

Sería un error convertir esta secuencia en una prohibición de la recuperación automática. RFC 9161, dedicado a las funciones Proxy ARP y Proxy ND en EVPN, contempla que el estado de IP duplicada se elimine por una corrección del operador o, alternativamente, al finalizar un temporizador de retención. El texto indica un valor predeterminado de 540 segundos y permite configurar los parámetros pertinentes.

La regla se refiere a ese estado de la función proxy. No promete que toda ruta MAC congelada en cualquier equipo EVPN se libere al cabo de nueve minutos. Tampoco convierte la expiración en una comprobación de que alguien retiró la asignación conflictiva del extremo. El temporizador cambia el tratamiento del estado retenido; no administra la configuración del equipo.

La liberación temporizada puede ser una política deliberada para evitar que un episodio transitorio deje una restricción indefinida. A cambio, obliga a comprender la posibilidad de recurrencia y qué entrada se vuelve a admitir. Una liberación explícita tiene otro coste: el servicio puede esperar, aunque la causa ya se haya corregido, hasta que llegue alguien con conocimientos y permisos.

La comparación útil enfrenta esas consecuencias. Elegir «manual» no demuestra por sí solo un mayor control, y elegir «automático» no elimina las decisiones previas sobre alcance y riesgo.

Las excepciones de direccionamiento también cuentan. Las especificaciones separan determinados comportamientos anycast de IPv6, como los anuncios de vecino con la bandera Override desactivada, de los procedimientos de detección de IP duplicada aquí tratados. Una presencia intencionada en varias ubicaciones no debe clasificarse automáticamente como un error de asignación.

La compatibilidad no distribuye capacidades nuevas

El registro de publicación de RFC 9721 lo identifica como Proposed Standard de abril de 2025. Es una información sobre el documento, no sobre las funciones que ejecuta cada equipo de una red concreta.

El registro de erratas, consultado el 8 de septiembre de 2026, ilustra una distinción importante. Una propuesta que cuestionaba la formulación de compatibilidad con implementaciones anteriores en el resumen fue rechazada. Sin embargo, el responsable de área que la examinó reconoció una limitación de los despliegues mixtos cuando se espera que un PE antiguo ejecute el nuevo movimiento de una IP hacia una MAC distinta. El rechazo diferenció la ausencia de la capacidad nueva de una incompatibilidad de la codificación o de los comportamientos previamente admitidos.

La propuesta rechazada no es una corrección adoptada que declare incompatible al RFC. Pero la palabra «compatible» tampoco permite suponer que una implementación antigua ejecutará una función nueva. La pregunta operativa debe ser qué PE intervienen en el movimiento previsto y si soportan el comportamiento del que depende la recuperación. Este artículo no ha establecido una matriz de soporte ni ha probado un despliegue mixto.

La interpretación de seguridad exige una cautela parecida. RFC 9721 considera que tráfico comprometido en el lado de los extremos puede hacer parecer móvil a un equipo legítimo y acabar marcándolo como duplicado. El mecanismo puede justificar protección sin identificar al responsable. A la inversa, la presión para restaurar el servicio no permite considerar inocuo cualquier movimiento repetido. La calificación requiere evidencia del entorno.

La unidad de responsabilidad sigue siendo el servicio

Heng Lu explica la misión de BTW como descripción de la realidad, no como defensa de una causa. Su análisis de las relaciones de agencia y los incentivos aporta una forma de preguntar quién puede actuar y quién soporta las consecuencias. No autoriza a trasladar sus críticas específicas a instituciones de registro a los ingenieros que operan EVPN.

En este caso, la pregunta es concreta: ¿se sigue el servicio desde la corrección del extremo hasta la liberación y la comprobación de alcance, o solo se registran tareas locales concluidas? Dos personas pueden haber realizado correctamente sus operaciones mientras el resultado que espera el cliente sigue entre ambas.

No se ha medido aquí una duración de avería ni se propone un umbral universal. Los documentos describen mecanismos y condiciones; el análisis identifica una responsabilidad que debe atravesarlos. Una restricción no debería permanecer sin dueño porque la corrección ocurrió en otra consola, ni darse por resuelto el conflicto solo porque es fácil ejecutar una liberación. El tramo intermedio también forma parte de la recuperación.