BGP ha imparato il prefisso, ma il traffico aggira ancora il tunnel

Il gateway della sede mostra il prefisso del cloud nella sua tabella BGP, la sessione con il fornitore è stabilita, eppure la richiesta di un utente verso quel prefisso esce dall'interfaccia sbagliata. Nulla è rotto come suggerisce il monitoraggio, perché «BGP l'ha imparato» è un'affermazione sul piano di controllo. Tra quella tabella e il pacchetto ci sono quattro transizioni separate, e il flusso si ferma esattamente a una di esse. Percorrere i cancelli in ordine e fermarsi al primo che fallisce.

Primo cancello: che cosa ha realmente inviato il vicino

Partire dal prefisso così come è stato ricevuto, non come riassunto. Cercare la rete e la maschera esatte nella tabella BGP e annotare il prossimo salto, il percorso AS e ogni community a cui una politica di importazione potrebbe corrispondere. Una rotta riassunta in una dashboard può nascondere il fatto che il prefisso specifico non è mai stato accettato.

La politica di importazione è il luogo abituale in cui una rotta scompare senza errore. Una lista di prefissi, un filtro di community o una mappa di rotte in ingresso possono scartare l'aggiornamento mentre la sessione resta attiva e sana, ed è per questo che una luce verde del vicino dimostra così poco. L'assenza di una riga di log non significa l'assenza di una decisione. Di solito significa che la decisione è stata presa in silenzio, esattamente come configurato.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Leggere l'output in quell'ordine. I primi due comandi dicono se l'informazione è arrivata e che cosa il pari dichiara di aver inviato; gli ultimi due dicono se qualcosa ha raggiunto le tabelle di routing e di inoltro. Un prefisso presente nel primo comando e assente nel terzo è un problema di selezione o di installazione, non di connettività.

Secondo cancello: selezione, poi installazione

BGP sceglie il percorso migliore, e il percorso scelto non viene installato automaticamente. Il prossimo salto deve risolversi, e un'altra fonte di rotte può già possedere quel prefisso con una distanza amministrativa migliore. Una rotta statica rimasta dalla migrazione vincerà facilmente su un percorso BGP valido e manderà il traffico altrove.

RFC 4271 tiene separati tre concetti: che cosa ha inviato un pari, che cosa questo parlante ha scelto come migliore e che cosa annuncerà in seguito. Sono ruoli concettuali, non tre database fisici che un fornitore deve esporre, ma è proprio questa separazione a rendere «è in BGP» una risposta incompleta.

Controllare anche quale contesto di routing si sta leggendo. Una rotta installata in una VRF a cui non appartiene l'interfaccia dell'utente è invisibile ai pacchetti di quell'utente, e la tabella sembra corretta per tutto il tempo.

Terzo cancello: la ricerca che si applica a questo flusso

Ora smettere di chiedere della rotta e cominciare a chiedere del pacchetto. Annotare l'indirizzo di origine dell'utente, la destinazione, il protocollo, la porta e l'interfaccia di ingresso, perché ciascuno di essi può selezionare una politica diversa. Poi guardare la ricerca che si applica a quella combinazione invece della tabella di routing generale.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Un prefisso più specifico è la sorpresa più comune qui, e una rotta di politica è la seconda. Entrambe scavalcano l'aggregato che si stava guardando, e nessuna delle due è visibile in un riepilogo della tabella BGP.

Un ping originato dal gateway stesso non è una prova sulla sessione di un utente. Indirizzo di origine diverso, percorso di politica diverso e spesso un risultato diverso. Provare con la stessa origine usata dall'applicazione, oppure accettare che il test risponda a un'altra domanda.

Quarto cancello: la metà remota del percorso

Se la ricerca locale seleziona il tunnel, il pacchetto deve comunque essere accettato dalla politica di protezione, consentito dalla regola di inoltro e ricevere una risposta da qualcosa dall'altra parte. Un'ACL crypto che non include la coppia di indirizzi scarterà il traffico mentre il tunnel si dichiara attivo, il che produce un timeout indistinguibile da un guasto di routing.

Il percorso di ritorno conta quanto quello in uscita. Il lato cloud deve sapere come raggiungere l'origine della sede, tramite una rotta o tramite una traduzione configurata deliberatamente. I percorsi di ritorno asimmetrici sono comuni nei progetti provati da una sola direzione.

Correlare una connessione autorizzata recente con tre osservazioni: la politica locale che ha corrisposto, i contatori del tunnel che si sono mossi e la ricezione sul lato remoto dove è visibile. Se i contatori non si muovono, il pacchetto non è mai entrato nel tunnel, qualunque cosa dica la tabella delle rotte. Se si muovono e non arriva nulla, il lato remoto lo sta scartando o instradando male. Questi due esiti portano a team completamente diversi.

Nominare la transizione che ha fallito

Scrivere il risultato come uno di cinque stati: non ricevuto, non accettato dalla politica, non selezionato, non installato o non corrispondente a questo flusso. Aggiungerne un sesto per il caso in cui il percorso locale è corretto e l'estremità remota non può rispondere. Quella frase è il risultato, ed è molto più utile di uno screenshot di un vicino stabilito.

Mantenere anche un test negativo nel piano di collaudo: una destinazione che non deve attraversare il tunnel, verificata dopo la modifica. Una lista di controllo che dimostra solo il percorso felice non intercetterà la regola ampia di politica che qualcuno aggiungerà alla prossima finestra di manutenzione.