Ruta nul·la d’NX-OS EVPN: mantén el descart dins d’un sol tenant

La sol·licitud arriba com un canvi d’una línia: bloqueja una adreça. Afegeixes una ruta d’host a Null0 dins del context del tenant, el prefix desapareix de la taula local tal com s’esperava i llavors comencen les preguntes. La ruta ha sortit de l’equip? Els VTEP remots han descartat o simplement han perdut l’abastabilitat? Ara hi ha un segon tenant afectat?

Una ruta estàtica local correcta només respon la primera d’aquestes preguntes, i per això un canvi de blackhole és en realitat tres resultats revisats i no una sola ordre.

Què ha de produir realment el canvi

Comença escrivint els tres resultats. El tenant previst ha de descartar la destinació localment. Només la ruta autoritzada es pot exportar, sense res més que viatgi amb ella. Cada VTEP receptor ha de seleccionar l’acció de descart prevista i no un camí diferent.

Cada resultat té les seves pròpies proves i cap no implica els altres. Una ruta Null0 local produeix descart local i, sense redistribució, no exporta absolutament res. Una ruta redistribuïda sense la community acordada arriba com un prefix ordinari i es reenvia. Una community sense la política de recepció pot ser ignorada del tot.

Escriure primer els resultats també et protegeix d’una fallada habitual: un canvi que sembla funcionar perquè la destinació ja era inabastable per un motiu no relacionat. Si no pots descriure com distingiries els dos casos, la prova d’acceptació encara no està dissenyada.

La declaració local només fa la primera part

Per a NX-OS a la línia 10.4(x), la ruta nul·la se situa dins del context VRF del tenant i no en una ordre única que anomeni la VRF. El fragment és curt i no és de cap manera una configuració EVPN completa.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

L’adreça és un prefix de documentació, no un objectiu. Fixa’t en la diferència de sintaxi respecte d’IOS, on el nom de la VRF apareix dins de la mateixa ordre de ruta, i confirma la forma admesa per a la versió que realment executes abans d’enganxar res.

Per si sola, aquesta línia descarta el trànsit d’aquell host dins de TENANT_A i no fa res més. No marca la ruta, no la selecciona per a BGP i no estableix cap community. Són decisions de configuració separades, i cadascuna és un punt on el canvi pot ser massa estret per funcionar o massa ampli per ser segur.

El descart local també afecta el trànsit legítim cap a la mateixa destinació. Si la intenció és aturar una font abusiva mentre els usuaris reals encara necessiten l’adreça, una ruta nul·la és l’eina equivocada i ho aprendràs a la primera trucada de suport.

Exportació i importació són acords separats

La redistribució és on es decideix l’abast. Restringeix els prefixos elegibles a la mitigació aprovada, mantén-la dins del tenant i limita els peers d’origen als que hi ha al disseny. Redistribuir totes les rutes estàtiques perquè una ruta d’host marcada ha de viatjar és com un canvi de manteniment es converteix en un incident d’encaminament.

La community BLACKHOLE és un acord sobre un valor ben conegut, no una autorització perquè qualsevol veí descarti qualsevol adreça. L’RFC 7999 la descriu en aquests termes, i la frontera de confiança sobre qui la pot anunciar forma part del disseny i no és un detall d’implementació.

El costat receptor necessita la seva pròpia configuració. A NX-OS, les rutes nul·les de tipus 5 requereixen tractament amb route-map al VTEP per seleccionar el comportament de descart, cosa que es documenta al costat dels passos d’exportació. Un dispositiu emissor que marca correctament i un receptor que ignora la marca produeixen un canvi que sembla aplicat i que reenvia el trànsit igualment.

Revisa el route-map per detectar efectes secundaris mentre hi siguis. Una política nova i restrictiva pot suprimir abastabilitat legítima de prefixos no relacionats, i aquest dany apareix més tard que el blackhole i és més difícil d’atribuir-hi.

Escriu la retirada abans de la inserció

Registra el propietari de la destinació, el motiu, l’aprovador i una caducitat abans de configurar res. Un descart sense caducitat es converteix en una entrada permanent l’origen de la qual ningú no recorda, i la següent persona que depuri l’adreça la tractarà com una part normal de la xarxa.

Mantén un camí de gestió independent que no depengui de la ruta que estàs canviant. Si la mitigació cobreix una adreça que fas servir per arribar al dispositiu, has creat un bloqueig amb passos extres.

Anomena el control exacte que retira la mitigació i prova aquesta retirada en un laboratori o en una finestra que et puguis permetre. Una retirada que ningú no ha assajat és un pla, no un procediment.

Accepta amb proves, no amb la sortida de l’ordre

Comprova l’estat d’encaminament seleccionat i l’estat de reenviament als VTEP previstos, i comprova una destinació veïna que ha de romandre intacta. Confirma que cap altre tenant no ha importat el prefix, perquè el vessament entre tenants és el mode de fallada que converteix una acció de manteniment en un incident.

Després retira la ruta i verifica que la ruta normal i el servei tornen. La guia de rutes nul·les d’EVPN a NX-OS per a la versió 10.4(x) documenta el marcatge, la redistribució i la política de recepció que es descriuen aquí, i és la referència amb què has de contrastar la teva pròpia versió.