Passaggio di consegne L3VPN: rotte private, una default o una tabella completa?

Il circuito è attivo, la VRF è configurata e il provider pone una domanda breve che decide il resto del progetto: che cosa deve ricevere il customer edge? Tre risposte sono comuni e nessuna deriva dal fatto che esista uno stack di label. Sono decisioni di servizio su dove il traffico esce dalla sede.

Ripercorrere il passaggio di consegne in ordine è il modo più economico per farlo bene. Si parte da ciò che accade al traffico che non corrisponde a nulla, poi si annotano i prefissi privati e il loro comportamento in caso di guasto, e solo dopo si parla di quanto grande sia il feed che si è disposti a trasportare.

Iniziare dal traffico che nessuno ha previsto

Prima che compaia qualsiasi elenco di prefissi, si ponga una domanda: quando un pacchetto non corrisponde a nessuna rotta privata, dove deve andare? Una sede con un proprio circuito internet di solito mantiene una default locale, così il traffico web ordinario esce dal firewall locale e non tocca mai il provider. In quel progetto la VPN trasporta solo le sedi private remote e sono i prefissi più specifici a fare la selezione.

Una sede destinata a usare un'uscita centrale è il caso opposto. Lì la default punta nel servizio e il provider o il sito centrale possiede l'inoltro, il routing di ritorno e qualsiasi traduzione. Dire "default verso la VPN" senza quel titolare produce una sede che risolve i nomi e non raggiunge nulla.

I due progetti differiscono in come si presenta un guasto di routing, ed è per questo che tirare a indovinare costa caro. Con una default locale, una rotta privata persa manda quel traffico su internet, dove il firewall lo scarta o, peggio, risponde qualcosa che non si intendeva. Con una default centrale, la stessa perdita toglie del tutto l'accesso a internet e il ticket arriva come "tutta la sede è giù". Nessuno dei due guasti è sbagliato in sé, ma solo uno corrisponde al servizio venduto, e una configurazione BGP da sola non dice quale sia stato costruito.

Annotare i prefissi privati con il loro caso di guasto

Elenca i prefissi che la sede deve raggiungere e annota quali sono riassunti. Un aggregato più largo di un bit trascina destinazioni sconosciute nella VPN, il che va bene solo se il lato remoto le possiede davvero e le inoltra.

Poi descrivi il comportamento previsto quando il servizio privato si guasta. Una rotta di scarto mantenuta tiene il traffico fuori da un percorso non autorizzato e produce un'interruzione pulita e attesa. Una default mobile può preservare la disponibilità spostandosi su un percorso di backup, ma solo se quel percorso è autorizzato a portare quel traffico.

Tieni disponibilità e fallback consentito come due requisiti separati nel documento di consegna. I team che li fondono finiscono per discutere se la sede sarebbe dovuta cadere, invece di verificare se la politica concordata è stata attuata.

Verificare che cosa ha davvero installato la CE

L'intento di configurazione e lo stato di inoltro divergono abbastanza spesso che la verifica appartiene alla consegna, non alla revisione dell'incidente. Su un customer edge IOS-XE i tre comandi sotto rispondono a tre domande diverse: che cosa è stato offerto, che cosa è stato accettato e che cosa è realmente in uso.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Esegui tutti e tre il giorno della consegna, non un mese dopo, finché qualcuno ricorda ancora che cosa è stato concordato. Il primo output dipende da soft-reconfiguration inbound o da un route refresh memorizzato; senza l'uno o l'altro, la CE non può mostrarti ciò che ha rifiutato. Il secondo mostra i percorsi accettati e migliori dopo la policy. Il terzo dice dove va davvero la default, ed è la riga più utile di tutta la consegna.

Esegui gli stessi controlli su una seconda CE se la sede è a doppio collegamento. Un'accettazione asimmetrica tra due edge è una causa comune di "funziona da un server e non dall'altro", ed è invisibile in un diff di configurazione che sembra simmetrico.

Qualificare un feed più grande invece di presumerlo

A volte il cliente ha davvero bisogno delle informazioni di percorso internet dentro la VRF, per il policy routing o per un'uscita centrale che instrada per prefisso. È un requisito da dichiarare, delimitare e prezzare, non una default nascosta. Comporta memoria per RIB e FIB, CPU per gli aggiornamenti, manutenzione dei filtri e un titolare per la tabella risultante.

Le argomentazioni sulla capacità sbagliano in entrambe le direzioni. Una tabella completa non è vietata dentro una VRF, e non è nemmeno gratuita. Allo stesso modo, non si può dedurre il costo di oggi da un vecchio conteggio di rotte, e un'allocazione di label più piccola non elimina il costo di memorizzare le rotte.

La specifica BGP/MPLS IP VPN discute diversi assetti di accesso a internet accanto al servizio VPN stesso e non dichiara una tabella completa né una default obbligatorie per ogni cliente, ed è la sezione da indicare quando compare un'affermazione sulla "pratica standard": RFC 4364.

Chiudi la consegna registrando l'insieme annunciato, quello ricevuto e quello selezionato accanto alla politica di uscita concordata, e provando una destinazione privata, una destinazione pubblica prevista e un caso di perdita di rotta. Un verbale firmato di quelle tre prove risolve più discussioni di qualsiasi affermazione su ciò che fanno la maggior parte delle reti.