Politica di export di Junos: il nome non è la condizione di corrispondenza

Qualcuno ha chiamato una politica EXPORT-STATIC, l’ha collegata e ora si chiede perché un prefisso dell’istanza di routing VPN non raggiunga mai l’estremità remota. Il nome non ha alcun effetto sulla selezione. Una politica è una definizione più un collegamento, e ciò che esporta è deciso dalle sue condizioni di corrispondenza, dai suoi termini ordinati e dal contesto che la usa. Leggete questi tre in quest’ordine, e il mistero di solito si riduce a un termine che non ha mai corrisposto.

Il nome è un’etichetta, non una condizione

Junos non interpreta i nomi delle politiche. Una politica che sarebbe ragionevole chiamare export statico può corrispondere al protocollo static, oppure corrispondere a un prefisso di indirizzo, oppure non corrispondere a nulla e accettare tutto ciò che passa. L’etichetta è documentazione scritta da chi l’ha creata, ed è esattamente affidabile quanto la memoria che quella persona ha dell’intenzione.

Trattate un risultato di export sorprendente come una richiesta di leggere la definizione, non come prova che il collegamento è rotto. Leggete la definizione e lasciate che contraddica l’etichetta.

Trovate il collegamento prima dei termini

Una definizione corretta collegata nel posto sbagliato cambia un altro scambio. Stabilite quale istanza di routing, protocollo e vicino o gruppo fanno realmente riferimento alla politica, perché una politica collegata sotto un gruppo BGP non influenza un altro, e una politica collegata all’istanza non si applica necessariamente a ogni protocollo al suo interno. Junos distingue questi livelli, e un export mancante a livello di gruppo è comune quando l’intenzione è stata espressa a livello di istanza.

Annotate il percorso del collegamento prima di leggere un solo termine. Metà di queste indagini finisce lì, con la definizione intatta e l’istruzione di export spostata. Registrate la differenza nel registro delle modifiche perché nessuno la annulli come errore.

I termini vengono valutati in ordine, e la prima decisione vince

I termini vanno dal primo all’ultimo, e un termine che accetta o rifiuta è una decisione finale. Un termine successivo che sembra l’eccezione prevista non viene mai eseguito se un termine precedente ha già deciso il destino della rotta, ed è per questo che una politica può leggersi correttamente dall’alto verso il basso e comportarsi comunque contro l’intenzione. Controllate l’ordine rispetto alla rotta che vi interessa, non rispetto all’ordine in cui i termini sono stati digitati.

Un termine che omette la sua azione non termina; la valutazione prosegue al termine successivo, e il risultato finale dipende da ciò che segue e dal valore predefinito applicabile. È una costruzione davvero utile e una fonte affidabile di sorprese quando non è intenzionale.

Un esempio che esporta solo rotte statiche, con il collegamento sul gruppo:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

Un prefisso appreso tramite OSPF invece che configurato come rotta statica fallisce la corrispondenza e viene scartato, qualunque sia il nome della politica.

Le azioni modificano una copia, non la rotta originale

Le azioni della politica operano sulla rotta così come viene valutata per quell’annuncio, cioè su una copia e non sulla voce della tabella di routing. Un comando locale show route può quindi mostrare una rotta con un insieme di attributi mentre la versione esportata ne porta altri, e l’originale non viene riscritto dall’export. Questa distinzione spiega diverse discussioni su quale output sia corretto: entrambi lo sono, e descrivono oggetti diversi. Dite quale vista state citando ogni volta che due ingegneri sono in disaccordo su un attributo di rotta.

Accettare e rifiutare sono decisioni finali; le modifiche agli attributi non necessariamente lo sono. Non date per scontato che impostare una community termini la politica, perché la valutazione può proseguire in termini che non avete considerato.

Confrontate la vista annunciata con l’aspettativa

Usate la vista specifica del protocollo sul peer reale, ad esempio show route advertising-protocol bgp 192.0.2.1, e leggetela nel contesto corretto dell’istanza di routing. Una rotta presente in una VRF non ha necessariamente superato la politica di export, e una rotta che compare nell’output annunciato non è necessariamente stata accettata dall’estremità remota. Sono tre stati separati e falliscono in modi diversi.

Accettate il progetto con un prefisso che deve essere annunciato e uno che deve rimanere locale. Questo dà alla politica un contratto che potete testare, ed evita la correzione alternativa di ampliare l’export finché non compare finalmente una rotta con un nome.