Sessione BGP attiva, percorso del cliente rotto: MPLS su DMVPN

Il peering è attivo da settimane, il conteggio dei prefissi sembra corretto e, ciò nonostante, il traffico di un cliente prende ancora la strada lunga o non arriva mai. Due cose diverse vengono giudicate dallo stesso indicatore. Una sessione BGP riporta che due peer possono scambiarsi messaggi su una connessione TCP; non dice nulla sulla capacità dell'overlay di trasportare un pacchetto etichettato per quel preciso cliente.

Questo divario si vede più facilmente in un progetto MPLS su DMVPN, dove il percorso attraverso l'hub e il percorso diretto attraverso lo spoke possono comportarsi diversamente per ragioni che non hanno nulla a che fare con il peering.

Cosa dimostra davvero la sessione

BGP gira su TCP, quindi ogni peer ha bisogno di una rotta verso l'indirizzo dell'altro estremo prima che accada qualsiasi altra cosa. Scegliete un loopback come estremo e avrete creato un requisito di raggiungibilità, non una garanzia di inoltro. La sessione può poi restare attiva attraverso un'interfaccia che il traffico del cliente non userebbe mai.

Annotate quattro fatti a entrambi gli estremi prima di trarre conclusioni: l'indirizzo di origine della sessione, il suo indirizzo di destinazione, il contesto di instradamento in cui si trova e quale interfaccia sceglierebbe il kernel o il router per quella coppia. Questi fatti descrivono il piano di controllo. I pacchetti del cliente vi aggiungono un VRF, una pila di etichette e una mappatura di overlay.

Quattro meccanismi, non uno

La documentazione Cisco su MPLS su DMVPN separa nettamente i pezzi. MP-BGP distribuisce le etichette di overlay del cliente tra i dispositivi di bordo del provider. MPLS usa quelle etichette per selezionare il contesto di inoltro di un pacchetto. NHRP mappa un indirizzo di overlay all'estremo di trasporto che un tunnel dinamico richiede. IPsec protegge il percorso tra peer dove si applica.

Uno qualsiasi dei quattro può essere corretto mentre un altro è sbagliato, ed è la combinazione a trasportare il traffico. Uno scambio di rotte può completarsi mentre manca il binding dell'etichetta per un VRF, mentre la mappatura NHRP punta a un indirizzo di trasporto obsoleto o mentre il tunnel esiste ma nessuna policy consente il pacchetto interno. Nessuna di queste condizioni fa cadere la sessione.

Confrontate il percorso attraverso l'hub con la scorciatoia, una variabile alla volta

Fissate l'host di origine, l'host di destinazione e il VRF, poi seguite due volte lo stesso flusso. Sul percorso attraverso l'hub annotate il salto successivo, l'etichetta di servizio che identifica il contesto del cliente remoto e la mappatura overlay-verso-trasporto in uso. Sul percorso diretto previsto annotate le stesse tre cose. La differenza tra i due elenchi è il guasto, o la sua assenza.

Mantenete costante il flusso durante il confronto. Cambiare l'host di origine, il VRF o la destinazione tra un'osservazione e l'altra produce due storie scollegate, ed è il modo più comune in cui questo esercizio va storto.

Tenete i test di loopback nel loro scomparto

Un ping con origine nel loopback di un router è un test utile, ed esercita un caso diverso da un flusso da un host. L'indirizzo di origine appartiene al router, il suo contesto di instradamento può essere globale invece che un VRF, e il percorso di ritorno può differire da quello che prenderebbe un prefisso del cliente. Quindi il loopback che risponde e l'applicazione che funziona tramite la scorciatoia sono risultati separati, e solo il secondo descrive il cliente.

Provate entrambi, poi etichettateli separatamente nelle vostre note. Quando non concordano, avete imparato qualcosa di preciso su dove il progetto diverge, ed è più di quanto una singola spunta verde vi dirà mai.

Le affermazioni sulle versioni e sui difetti richiedono prove proprie

I rapporti dal campo a volte consigliano di cambiare una maschera host o un indirizzo di origine BGP, e tali rapporti vale la pena leggerli solo accanto al difetto su cui sono stati scritti e alle release che ha colpito. Una soluzione temporanea di una release non è l'affermazione che l'architettura non supporti alcun prefisso /32.

Usate documentazione che corrisponda alla vostra fase DMVPN, alla piattaforma e alla release, e ricordate che un capitolo può coprire più configurazioni, inclusa FlexVPN. Un esempio tratto da una configurazione non si trasferisce in silenzio a un'altra. Scegliete gli estremi della sessione per il progetto del piano di controllo che vi serve davvero, poi verificate separatamente il percorso di inoltro del cliente, perché riscrivere ogni maschera di loopback non sostituisce lo scoprire quale compito è fallito.