Rotta nulla NX-OS EVPN: tenere lo scarto dentro un solo tenant

La richiesta arriva come una modifica di una riga: mettere in blackhole un indirizzo. Si aggiunge una rotta host verso Null0 nel contesto del tenant, il prefisso scompare dalla tabella locale come previsto, e poi iniziano le domande. La rotta ha lasciato l’apparato? I VTEP remoti hanno scartato o hanno semplicemente perso la raggiungibilità? Ora è coinvolto un secondo tenant?

Una rotta statica locale corretta risponde solo alla prima di queste domande, ed è per questo che una modifica di blackhole è in realtà tre esiti verificati e non un singolo comando.

Che cosa deve produrre davvero la modifica

Inizia scrivendo i tre esiti. Il tenant previsto deve scartare la destinazione localmente. Solo la rotta autorizzata può essere esportata, senza nient’altro che viaggi con essa. Ogni VTEP ricevente deve selezionare l’azione di scarto prevista e non un percorso diverso.

Ogni esito ha le proprie prove e nessuno implica gli altri. Una rotta Null0 locale produce scarto locale e, senza redistribuzione, non esporta assolutamente nulla. Una rotta redistribuita senza la community concordata arriva come prefisso ordinario e viene inoltrata. Una community senza la politica di ricezione può essere ignorata del tutto.

Scrivere prima gli esiti ti protegge anche da un guasto comune: una modifica che sembra funzionare perché la destinazione era già irraggiungibile per un motivo non correlato. Se non riesci a descrivere come distingueresti i due casi, il test di accettazione non è ancora progettato.

L’istruzione locale fa solo la prima parte

Per NX-OS nel ramo 10.4(x), la rotta nulla si trova nel contesto VRF del tenant e non in un singolo comando che nomina la VRF. Il frammento è breve e non è affatto una configurazione EVPN completa.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

L’indirizzo è un prefisso di documentazione, non un obiettivo. Nota la differenza di sintassi rispetto a IOS, dove il nome della VRF compare dentro il comando di rotta stesso, e conferma la forma supportata per la release che esegui davvero prima di incollare qualsiasi cosa.

Da sola questa riga scarta il traffico verso quell’host dentro TENANT_A e non fa nient’altro. Non etichetta la rotta, non la seleziona per BGP e non imposta una community. Sono decisioni di configurazione separate, e ciascuna è un punto in cui la modifica può essere troppo stretta per funzionare o troppo ampia per essere sicura.

Lo scarto locale colpisce anche il traffico legittimo verso la stessa destinazione. Se l’intento è fermare una sorgente abusiva mentre gli utenti reali hanno ancora bisogno dell’indirizzo, una rotta nulla è lo strumento sbagliato e lo imparerai alla prima chiamata al supporto.

Esportazione e importazione sono accordi separati

La redistribuzione è dove si decide l’ambito. Limita i prefissi idonei alla mitigazione approvata, tienila dentro il tenant e limita i peer di origine a quelli del progetto. Redistribuire ogni rotta statica perché una rotta host etichettata deve viaggiare è il modo in cui una modifica di manutenzione diventa un incidente di routing.

La community BLACKHOLE è un accordo su un valore ben noto, non un’autorizzazione per qualsiasi vicino a scartare qualsiasi indirizzo. L’RFC 7999 la descrive in questi termini, e il confine di fiducia su chi possa annunciarla fa parte del progetto e non è un dettaglio implementativo.

Il lato ricevente ha bisogno della propria configurazione. Su NX-OS, le rotte nulle di tipo 5 richiedono un trattamento route-map sul VTEP per selezionare il comportamento di scarto, documentato insieme ai passaggi di esportazione. Un apparato mittente che etichetta correttamente e un ricevente che ignora l’etichetta producono una modifica che sembra applicata e che inoltra comunque il traffico.

Esamina la route-map per gli effetti collaterali mentre sei lì. Una nuova politica restrittiva può sopprimere la raggiungibilità legittima di prefissi non correlati, e quel danno compare più tardi del blackhole ed è più difficile da attribuirgli.

Scrivi il ritiro prima dell’inserimento

Registra il proprietario della destinazione, il motivo, l’approvatore e una scadenza prima che qualsiasi cosa venga configurata. Uno scarto senza scadenza diventa una voce permanente di cui nessuno ricorda l’origine, e la prossima persona che eseguirà il debug dell’indirizzo la tratterà come una parte normale della rete.

Mantieni un percorso di gestione indipendente che non dipenda dalla rotta che stai modificando. Se la mitigazione copre un indirizzo che usi per raggiungere l’apparato, hai creato un blocco con passaggi aggiuntivi.

Nomina il controllo esatto che rimuove la mitigazione e prova quel ritiro in laboratorio o in una finestra che puoi permetterti. Un ritiro che nessuno ha provato è un piano e non una procedura.

Accetta con le prove, non con l’output del comando

Verifica lo stato di routing selezionato e lo stato di inoltro sui VTEP previsti, e verifica una destinazione vicina che deve restare intatta. Conferma che nessun altro tenant abbia importato il prefisso, perché la fuga tra tenant è la modalità di guasto che trasforma un’azione di manutenzione in un incidente.

Poi ritira e verifica che la rotta normale e il servizio tornino. La guida alle rotte nulle di NX-OS EVPN per la release 10.4(x) documenta l’etichettatura, la redistribuzione e la politica di ricezione descritte qui, ed è il riferimento con cui confrontare la tua release.