Ruta nula en NX-OS EVPN: mantén el descarte dentro de un solo tenant

La petición llega como un cambio de una línea: bloquear una dirección. Añades una ruta de host hacia Null0 dentro del contexto del tenant, el prefijo desaparece de la tabla local como se esperaba y entonces empiezan las preguntas. ¿Salió la ruta del equipo? ¿Descartaron los VTEP remotos o simplemente perdieron la accesibilidad? ¿Hay ahora un segundo tenant afectado?

Una ruta estática local correcta responde solo a la primera de esas preguntas, y por eso un cambio de blackhole es en realidad tres resultados revisados y no un único comando.

Qué debe producir realmente el cambio

Empieza escribiendo los tres resultados. El tenant previsto debe descartar el destino localmente. Solo la ruta autorizada puede exportarse, sin nada más que viaje con ella. Cada VTEP receptor debe seleccionar la acción de descarte prevista y no una ruta distinta.

Cada resultado tiene sus propias pruebas y ninguno implica a los demás. Una ruta Null0 local produce descarte local y, sin redistribución, no exporta absolutamente nada. Una ruta redistribuida sin la community acordada llega como un prefijo ordinario y se reenvía. Una community sin la política de recepción puede ignorarse por completo.

Escribir primero los resultados también te protege de un fallo habitual: un cambio que parece funcionar porque el destino ya era inalcanzable por un motivo no relacionado. Si no puedes describir cómo distinguirías ambos casos, la prueba de aceptación aún no está diseñada.

La sentencia local solo hace la primera parte

En NX-OS de la rama 10.4(x), la ruta nula se sitúa dentro del contexto VRF del tenant y no en un único comando que nombre la VRF. El fragmento es corto y no es en absoluto una configuración EVPN completa.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

La dirección es un prefijo de documentación, no un objetivo. Fíjate en la diferencia de sintaxis con IOS, donde el nombre de la VRF aparece dentro del propio comando de ruta, y confirma la forma admitida para la versión que realmente ejecutas antes de pegar nada.

Por sí sola, esta línea descarta el tráfico de ese host dentro de TENANT_A y no hace nada más. No etiqueta la ruta, no la selecciona para BGP y no establece ninguna community. Son decisiones de configuración separadas, y cada una es un punto donde el cambio puede ser demasiado estrecho para funcionar o demasiado amplio para ser seguro.

El descarte local también afecta al tráfico legítimo hacia el mismo destino. Si la intención es detener una fuente abusiva mientras los usuarios reales siguen necesitando la dirección, una ruta nula es la herramienta equivocada y lo aprenderás en la primera llamada de soporte.

Exportación e importación son acuerdos separados

La redistribución es donde se decide el alcance. Restringe los prefijos elegibles a la mitigación aprobada, mantenla dentro del tenant y limita los peers de origen a los que figuran en el diseño. Redistribuir todas las rutas estáticas porque una ruta de host etiquetada necesita viajar es la forma en que un cambio de mantenimiento se convierte en un incidente de encaminamiento.

La community BLACKHOLE es un acuerdo sobre un valor bien conocido, no una autorización para que cualquier vecino descarte cualquier dirección. El RFC 7999 la describe en esos términos, y la frontera de confianza sobre quién puede anunciarla forma parte del diseño y no es un detalle de implementación.

El lado receptor necesita su propia configuración. En NX-OS, las rutas nulas de tipo 5 requieren tratamiento con route-map en el VTEP para seleccionar el comportamiento de descarte, lo que se documenta junto a los pasos de exportación. Un dispositivo emisor que etiqueta correctamente y un receptor que ignora la etiqueta producen un cambio que parece aplicado y que reenvía el tráfico de todos modos.

Revisa el route-map en busca de efectos secundarios mientras estés allí. Una política nueva y restrictiva puede suprimir accesibilidad legítima de prefijos no relacionados, y ese daño aparece más tarde que el blackhole y es más difícil de atribuirle.

Escribe la retirada antes de la inserción

Registra el propietario del destino, el motivo, al aprobador y una caducidad antes de configurar nada. Un descarte sin caducidad se convierte en una entrada permanente cuyo origen nadie recuerda, y la siguiente persona que depure la dirección la tratará como una parte normal de la red.

Mantén una vía de gestión independiente que no dependa de la ruta que estás cambiando. Si la mitigación cubre una dirección que usas para llegar al dispositivo, has creado un bloqueo con pasos extra.

Nombra el control exacto que retira la mitigación y prueba esa retirada en un laboratorio o durante una ventana que puedas permitirte. Una retirada que nadie ha ensayado es un plan y no un procedimiento.

Acepta con pruebas, no con la salida del comando

Comprueba el estado de encaminamiento seleccionado y el estado de reenvío en los VTEP previstos, y comprueba un destino vecino que debe permanecer intacto. Confirma que ningún otro tenant ha importado el prefijo, porque la fuga entre tenants es el modo de fallo que convierte una acción de mantenimiento en un incidente.

Después retira la ruta y verifica que la ruta normal y el servicio vuelven. La guía de rutas nulas de NX-OS EVPN para la versión 10.4(x) documenta el etiquetado, la redistribución y la política de recepción descritos aquí, y es la referencia con la que contrastar tu propia versión.