Ruta nula en NX-OS EVPN: mantén o descarte dentro dun só tenant

A petición chega como un cambio dunha liña: bloquear un enderezo. Engades unha ruta de host cara a Null0 dentro do contexto do tenant, o prefixo desaparece da táboa local como se esperaba e entón comezan as preguntas. Saíu a ruta do equipo? Descartaron os VTEP remotos ou simplemente perderon a accesibilidade? Hai agora un segundo tenant afectado?

Unha ruta estática local correcta responde só á primeira desas preguntas, e por iso un cambio de blackhole é en realidade tres resultados revisados e non un único comando.

Que debe producir realmente o cambio

Empeza escribindo os tres resultados. O tenant previsto debe descartar o destino localmente. Só a ruta autorizada pode exportarse, sen nada máis que viaxe con ela. Cada VTEP receptor debe seleccionar a acción de descarte prevista e non unha ruta distinta.

Cada resultado ten as súas propias probas e ningún implica os demais. Unha ruta Null0 local produce descarte local e, sen redistribución, non exporta absolutamente nada. Unha ruta redistribuída sen a community acordada chega como un prefixo ordinario e reenvíase. Unha community sen a política de recepción pode ignorarse por completo.

Escribir primeiro os resultados tamén te protexe dun fallo habitual: un cambio que parece funcionar porque o destino xa era inalcanzable por un motivo non relacionado. Se non podes describir como distinguirías ambos os casos, a proba de aceptación aínda non está deseñada.

A sentenza local só fai a primeira parte

En NX-OS da rama 10.4(x), a ruta nula sitúase dentro do contexto VRF do tenant e non nun único comando que nomee a VRF. O fragmento é curto e non é en absoluto unha configuración EVPN completa.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

O enderezo é un prefixo de documentación, non un obxectivo. Fíxate na diferenza de sintaxe con IOS, onde o nome da VRF aparece dentro do propio comando de ruta, e confirma a forma admitida para a versión que realmente executas antes de pegar nada.

Por si soa, esta liña descarta o tráfico dese host dentro de TENANT_A e non fai nada máis. Non etiqueta a ruta, non a selecciona para BGP e non establece ningunha community. Son decisións de configuración separadas, e cada unha é un punto onde o cambio pode ser demasiado estreito para funcionar ou demasiado amplo para ser seguro.

O descarte local tamén afecta o tráfico lexítimo cara ao mesmo destino. Se a intención é deter unha fonte abusiva mentres os usuarios reais seguen necesitando o enderezo, unha ruta nula é a ferramenta incorrecta e aprenderalo na primeira chamada de soporte.

Exportación e importación son acordos separados

A redistribución é onde se decide o alcance. Restrinxe os prefixos elixibles á mitigación aprobada, mantena dentro do tenant e limita os peers de orixe aos que figuran no deseño. Redistribuír todas as rutas estáticas porque unha ruta de host etiquetada necesita viaxar é a forma en que un cambio de mantemento se converte nun incidente de encamiñamento.

A community BLACKHOLE é un acordo sobre un valor ben coñecido, non unha autorización para que calquera veciño descarte calquera enderezo. O RFC 7999 descríbea neses termos, e a fronteira de confianza sobre quen pode anunciarla forma parte do deseño e non é un detalle de implementación.

O lado receptor necesita a súa propia configuración. En NX-OS, as rutas nulas de tipo 5 requiren tratamento con route-map no VTEP para seleccionar o comportamento de descarte, o que se documenta xunto cos pasos de exportación. Un dispositivo emisor que etiqueta correctamente e un receptor que ignora a etiqueta producen un cambio que parece aplicado e que reenvía o tráfico de todos os xeitos.

Revisa o route-map en busca de efectos secundarios mentres esteas alí. Unha política nova e restritiva pode suprimir accesibilidade lexítima de prefixos non relacionados, e ese dano aparece máis tarde que o blackhole e é máis difícil de atribuírlle.

Escribe a retirada antes da inserción

Rexistra o propietario do destino, o motivo, o aprobador e unha caducidade antes de configurar nada. Un descarte sen caducidade convértese nunha entrada permanente cuxa orixe ninguén recorda, e a seguinte persoa que depure o enderezo tratará como unha parte normal da rede.

Mantén unha vía de xestión independente que non dependa da ruta que estás cambiando. Se a mitigación cobre un enderezo que usas para chegar ao dispositivo, creaches un bloqueo con pasos extra.

Nomea o control exacto que retira a mitigación e proba esa retirada nun laboratorio ou durante unha xanela que poidas permitirche. Unha retirada que ninguén ensaiou é un plan e non un procedemento.

Acepta con probas, non coa saída do comando

Comproba o estado de encamiñamento seleccionado e o estado de reenvío nos VTEP previstos, e comproba un destino veciño que debe permanecer intacto. Confirma que ningún outro tenant importou o prefixo, porque a fuga entre tenants é o modo de fallo que converte unha acción de mantemento nun incidente.

Despois retira a ruta e verifica que a ruta normal e o servizo volven. A guía de rutas nulas de NX-OS EVPN para a versión 10.4(x) documenta o etiquetado, a redistribución e a política de recepción descritos aquí, e é a referencia coa que contrastar a túa propia versión.