Tipo di rotta OSPF attraverso una VPN: non sempre esterna

Un prefisso del cliente attraversa il cloud del provider come rotta BGP VPN e arriva al sito remoto con l’aspetto di una rotta OSPF esterna, cosa che molti ingegneri si aspettano e che non è l’unico esito possibile. Ciò che vede il CE remoto dipende dal dominio OSPF da cui proviene il prefisso e dal suo tipo di rotta originale, ed entrambi viaggiano con la rotta VPN. Supporre che ogni prefisso redistribuito diventi di tipo 5 porta a cambi di preferenza che non possono funzionare. Confrontate prima l’identificatore di dominio, non la distanza amministrativa.

Il modello PE-CE porta abbastanza contesto perché il PE ricevente ricostruisca un annuncio OSPF invece di inventarlo.

Cosa viaggia con la rotta

La RFC 4577 definisce gli attributi OSPF che accompagnano una rotta VPN: l’identificatore di dominio, la metrica e il tipo di rotta del sito di origine. Il PE ricevente li usa per decidere come un prefisso idoneo debba apparire al suo processo OSPF locale. Senza quegli attributi il PE remoto non avrebbe alcuna base per nulla oltre a una redistribuzione esterna. Per questo una rotta può arrivare come LSA inter-area anche se BGP l’ha trasportata nel mezzo.

Anche il tipo di area conta. Un’area stub o NSSA limita quali LSA possono entrare, quindi la stessa rotta VPN può essere presentata in modo diverso a seconda di dove si trova l’istanza OSPF ricevente. La politica di esportazione configurata può anche sovrascrivere la presentazione predefinita, il che è una scelta deliberata e non un effetto collaterale.

Stesso dominio, presentazione diversa

Una rotta intra-area o inter-area dello stesso dominio arriva di solito al sito remoto come rotta inter-area, una LSA di tipo 3. Un prefisso di un altro dominio, un’origine che non ha mai parlato OSPF o un annuncio OSPF inizialmente esterno seguono invece le regole esterne, ed è lì che compaiono il tipo 5 e il suo equivalente NSSA. Entrambi i comportamenti sono corretti; l’input è diverso. Confrontate identificatori di dominio e attributi annunciati prima di toccare i valori di preferenza.

La distanza amministrativa sceglie tra le origini su un solo router. Non riscrive un tipo di LSA né crea la relazione di dominio mancante.

Quando uno sham link è la risposta giusta

Immaginate due siti nella stessa area collegati da un link backdoor diretto. OSPF mantiene quel percorso intra-area invece di quello inter-area offerto dal provider, anche quando i costi configurati renderebbero attraente il percorso del provider. Uno sham link rappresenta una relazione intra-area attraverso la VPN perché i costi possano partecipare alla decisione. Esiste per quel problema specifico di selezione del percorso, non per far sembrare interne tutte le rotte dello stesso dominio.

Uno sham link richiede estremi raggiungibili e configurazione reciproca su entrambi i PE. Configurarlo solo da un lato produce una relazione che non si forma mai, e la tabella di routing conserva la sua vecchia preferenza, il che sembra che la funzione non abbia fatto nulla.

Non spezzate la protezione dai loop

Il modello PE-CE imposta il bit DN sulle rotte che distribuisce affinché un prefisso non possa tornare attraverso un altro CE ed essere redistribuito una seconda volta. Questa protezione è ciò che impedisce a un prefisso di entrare in loop tra siti che condividono un dominio OSPF. Rimuoverla o ignorarla per far sembrare interna una rotta può creare esattamente il loop che era progettata a prevenire. Quando un prefisso sembra sbagliato, trattate il bit DN come informazione e non come ostacolo.

La stessa cautela vale per i filtri di redistribuzione e le mappe di rotte che rimuovono le community. Ciascuno rimuove contesto che il lato remoto necessita, e l’annuncio risultante può sembrare plausibile mentre è sbagliato. Cambiate un attributo alla volta e verificate ciò che il CE remoto installa realmente.

Poi verificate dal sito remoto: il tipo di LSA, il router annunciante e il percorso scelto. Quelle prove rispondono alla domanda posta dal ticket.