Perché la tua sessione BGP non compare nella tabella di routing della VPC

La storia che viene ripetuta è che un demone di routing su un appliance VPN EC2 insegnerà alla VPC i suoi prefissi remoti non appena BGP sale. Metà di questo è vero. La sessione sale, e nulla cambia nella tabella di routing della VPC per questo, ed è per questo che il primo sintomo è di solito una sottorete che manda silenziosamente il traffico in un buco nero.

Qui si confondono due cose diverse: il peering con un route server e l’installazione di rotte in una tabella.

Il mito: alza BGP e la VPC imparerà i prefissi

BGP è una conversazione tra due interlocutori, e in questo progetto gli interlocutori sono il demone di routing sul tuo appliance e un endpoint VPC Route Server che AWS colloca in una sottorete di tua proprietà. Quella conversazione trasporta prefissi. Non tocca la tabella di routing delle tue sottoreti di workload, perché quelle tabelle imparano solo attraverso la propagazione che va abilitata su ciascuna. Finché questo non accade, il tessuto della VPC non sa nulla di ciò che sa l’appliance.

I passaggi di configurazione sono separati per un motivo: associare, creare l’endpoint, fare peering, poi abilitare la propagazione.

Route Server è un piano di controllo, non un tunnel

Route Server non cifra, non inoltra e non ispeziona nemmeno un pacchetto. Esiste per scambiare BGP con l’appliance e consegnare i prefissi risultanti alle tabelle di routing configurate per riceverli. Il piano dati è invariato: i pacchetti escono ancora dall’interfaccia di rete dell’appliance, viaggiano nella sua VPN e tornano per la stessa strada.

Ciò significa che il controllo di origine e destinazione sull’istanza di inoltro conta ancora, perché l’istanza ora inoltra traffico indirizzato a qualcun altro.

Anche i gruppi di sicurezza e i controlli di sottorete si applicano al flusso inoltrato. Route Server non farà inoltrare il traffico a un appliance che lo scarta, e non riparerà una rotta di ritorno mancante sul lato remoto.

La propagazione è per tabella di routing, non per VPC

Associare il route server alla VPC e abilitare la propagazione su una tabella di routing sono due decisioni, e solo la seconda cambia ciò che fa una sottorete. Una VPC con sei tabelle di routing può ricevere un prefisso propagato in una e non nelle altre cinque, che è esattamente corretto per una sottorete hub ed esattamente ciò che produce il risultato sconcertante «funziona a metà». Anche dove la propagazione è attiva, una rotta concorrente può vincere, perché la selezione delle rotte della VPC preferisce il prefisso più lungo e, a parità di lunghezza, preferisce una rotta statica a una propagata. Questa preferenza viene applicata in silenzio.

Controlla la tabella effettiva per la sottorete specifica invece dell’elenco dei prefissi che l’appliance annuncia. L’API risponde direttamente a questa domanda: aws ec2 associate-route-server e aws ec2 enable-route-server-propagation --route-table-id <id> sono i due passaggi che le persone dimenticano, e aws ec2 describe-route-tables --route-table-ids <id> mostra se il prefisso è arrivato come voce di route server.

L’appliance trasporta ancora ogni pacchetto

Annunciare la raggiungibilità non è la stessa cosa che averla. Una sessione BGP può restare stabilita mentre la VPN dell’appliance è giù, e un annuncio statico che non cambia mai continua a tirare il traffico verso un percorso morto. Route Server supporta il rilevamento dei guasti come BFD, ma questo verifica la vitalità del peer, non la salute di tutto ciò che sta dietro.

Lega l’annuncio alla rotta remota reale: annuncia il prefisso quando il tunnel e la rete remota sono attivi, e ritiralo quando non lo sono.

Ritira un prefisso e guarda cosa succede

Prova per fasi, e fai dell’ultima fase una rimozione. Conferma che l’annuncio arrivi, che il prefisso compaia in ogni tabella prevista, che l’appliance sia il prossimo hop, che l’inoltro attraversi il tunnel attivo e che l’estremità remota risponda. Poi ritira un prefisso di test, o chiudi un tunnel approvato, e osserva se il traffico si sposta dove il progetto dice che dovrebbe. Annota le tabelle prima e dopo mentre il test è ancora aperto.

Spostare una rotta su un secondo appliance non sposta le sessioni che trasportava, perché lo stato NAT e del firewall resta sul primo dispositivo.

Per un insieme fisso di una dozzina di prefissi, le rotte statiche nelle tabelle della VPC restano la risposta più economica. Route Server si guadagna il suo posto quando l’elenco dei prefissi cambia davvero e la politica di ritiro è qualcosa che puoi spiegare alla persona in reperibilità.