Routing delle filiali MPLS: cosa impara la CE, e da chi

Un host di una filiale apre una connessione verso un server di un’altra, ed entrambe le sedi si trovano dietro la stessa VPN MPLS di livello 3 gestita. L’host conosce solo il proprio gateway predefinito e nulla più, il che è corretto. L’importante è che il bordo cliente locale consegni il pacchetto al proprio bordo provider, e che lo stato di routing VPN del provider lo porti alla filiale che possiede il prefisso di destinazione.

Seguire un pacchetto lungo il percorso è il modo più rapido per vedere quale parte è responsabilità del cliente e quale parte appartiene al servizio.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Dove finisce il lavoro di ogni salto

La CE-A ha bisogno di una rotta verso la LAN remota che punti al proprio collegamento locale con il provider, non all’indirizzo WAN della filiale remota. Poi il provider trasporta il pacchetto attraverso il proprio core usando lo stato di routing VPN, e la CE-B lo consegna sulla LAN di destinazione. In nessun momento un host deve capire etichette, VRF o il circuito internet dell’altro lato.

L’errore che ricorre nei ticket è configurare l’indirizzo WAN della filiale B come next hop sulla filiale A. Entrambe le filiali hanno comprato lo stesso servizio, quindi sembra che debbano essere vicine. Non lo sono: un next hop deve essere raggiungibile attraverso il progetto di routing che si ha davvero, e la CE remota di solito è a molti salti di distanza, dietro apparati che non si amministrano. Una rotta statica costruita su questo presupposto appare attiva e non risolve verso nulla, il che è peggio di una rotta mancante perché nella tabella sembra corretta.

La RFC 4364 separa lo scambio tra bordo cliente e bordo provider dalla distribuzione delle rotte VPN da parte del provider, ed è esattamente il confine di cui tratta questo manuale. Il compito del cliente è dire al proprio bordo cosa può consegnare e accettare la raggiungibilità che il servizio offre in cambio.

Su cosa deve concordare la consegna

Scegliere il meccanismo insieme al provider, non attorno a lui. Rotte statiche, BGP o un accordo di protocollo di routing tra CE e PE sono tutti legittimi, e OSPF ha un modello MPLS VPN definito per questa consegna. Nessuno di questi è un motivo per costruire un’adiacenza OSPF tra due bordi cliente remoti attraverso un core provider non specificato, perché è un progetto che il provider non ha accettato e non può supportare.

Prima che una nuova LAN entri in servizio, annota quattro cose: il prefisso, la rotta locale successiva sulla CE, l’annuncio che il provider accetterà e le rotte che il provider restituirà. Aggiungi qualsiasi filtraggio, limite di prefissi o restrizione tra sedi imposti dal contratto. Un’adiacenza sana è un canale per scambiare informazioni, e non è prova che un determinato prefisso sia stato accettato; la sessione può essere attiva mentre la nuova sottorete resta dentro un filtro.

Poi segui la risposta. La filiale B ha bisogno di una rotta di ritorno verso la LAN di origine, e l’host sul lato ricevente ha bisogno del proprio gateway e dei propri permessi di servizio. Una rotta che appare sulla CE-A stabilisce metà del viaggio di andata e ritorno, e metà viaggio è la ragione per cui una direzione di un test ping sembra sana mentre l’applicazione continua a fallire.

Verifica entrambe le consegne prima dell’approvazione

Raccogli lo stato di routing su entrambi i bordi cliente, conferma con il provider che i prefissi LAN previsti sono stati accettati nella VPN, poi prova un’applicazione consentita in ciascuna direzione. Le tabelle di routing da sole non dimostrano che l’applicazione funzioni, e un test dell’applicazione da solo non dice quale piano di controllo abbia fallito quando non funziona.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Leggi insieme i tre output. Il primo dice cosa crede il bordo, il secondo dice cosa ha appreso e da quale peer, e il terzo dice cosa inoltrerà realmente. La discrepanza tra loro è di solito un problema di policy o di ricorsione più che un annuncio mancante, e vale la pena risolverlo prima di chiedere al provider di indagare. Porta quei tre output alla chiamata con l’operatore, perché rispondono alla maggior parte delle domande che un ingegnere del supporto ti farebbe altrimenti.

Sapere cosa il servizio non fornisce

Questo è accesso instradato di livello 3. Non è un circuito di livello 2 che estende le trasmissioni tra uffici, quindi i protocolli di scoperta, le applicazioni dipendenti dalla trasmissione e le ipotesi di segmento condiviso non viaggiano con esso. La stampa, la navigazione dei nomi e qualsiasi cosa dipenda da un segmento locale richiedono un progetto proprio.

La separazione VPN non è nemmeno cifratura. La commutazione di etichetta tiene i clienti separati dentro la rete del provider, e non rende riservato il carico utile se il contratto richiede riservatezza. Dove questo conta, deve fornirlo l’applicazione o uno strato sovrapposto.

Infine, tieni il modello di servizio scritto accanto alla configurazione di routing della sede. Il prossimo ingegnere che aggiunge una sottorete dovrebbe poter leggere quali prefissi sono annunciati, chi li accetta e qual è il percorso di ritorno atteso: la specifica BGP/MPLS IP VPN è il riferimento per il modello che sta dietro a tutto questo.