Cisco 300-410: MPLS, VRF e Servizi VPN di Livello 3 — Guida allo studio
Fa parte della Cisco CCNP Enterprise 300-410 ENARSI — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.
Panoramica
Le VPN di Livello 3 basate su Multiprotocol Label Switching (MPLS) separano il routing dei clienti in istanze di routing e forwarding virtuali (VRF), utilizzando un core condiviso del provider per il trasporto. I router Provider Edge (PE) impongono e rimuovono gli stack di label in modo che i router del Provider (P) inoltrino il traffico basandosi esclusivamente sulle label, preservando scalabilità e isolamento. Il protocollo MP-BGP distribuisce le rotte VPN (VPNv4/VPNv6) con Route Distinguisher (RD) per garantirne l’unicità e Route Target (RT) per controllare le policy di importazione ed esportazione. Una progettazione corretta richiede una netta separazione dei ruoli tra cliente e provider, un’attenta distribuzione delle label e policy esplicite per il route leaking e i servizi condivisi. La gestione operativa richiede stati del control-plane prevedibili (IGP, LDP/RSVP, MP-BGP) e un comportamento deterministico del data-plane (stacking di label, PHP), con una verifica rigorosa e un isolamento dei guasti attraverso i confini CE–PE–core.
Forwarding MPLS e distribuzione delle label
Formato e stack delle label
- Un header shim MPLS contiene una label a 20 bit, una Traffic Class (TC/EXP) a 3 bit, un bit di Bottom of Stack (S) e un TTL a 8 bit.
- I pacchetti trasportano uno stack: una label esterna di “trasporto” per l’LSP da PE a PE e una label interna “VPN” che identifica la VRF (o il servizio) del PE di uscita.
- Il Penultimate Hop Popping (PHP) rimuove la label superiore sul penultimo router P per ridurre il carico sul PE di uscita; si può usare l’explicit-null per conservare la label superiore e preservare la semantica QoS/TTL fino all’uscita.
Fondamenti di LDP
- I router P e PE eseguono tipicamente un protocollo di gateway interno (IGP) per stabilire la raggiungibilità e il Label Distribution Protocol (LDP) per mappare le Forwarding Equivalence Class (FEC) alle label.
- LDP scopre i neighbor tramite messaggi “hello” su UDP/646 e forma sessioni per lo scambio di label su TCP/646, fornendo una segnalazione affidabile delle label. Il Targeted LDP (tLDP) può creare sessioni off-link per FEC specifiche.
- Stili di allocazione/propagazione delle label:
- Controllo indipendente vs ordinato: un router può allocare label per una FEC non appena conosce una rotta (indipendente) o solo dopo aver ricevuto una label dal suo next hop (ordinato).
- Ritenzione delle label liberale vs conservativa: mantenere tutte le label ricevute o solo quelle dal miglior next hop, scambiando memoria per agilità di convergenza.
- L’ID del router LDP è per default l’indirizzo di loopback più alto, se presente (altrimenti l’interfaccia attiva con indirizzo più alto). È importante stabilizzarlo (e il trasporto) per evitare il churn delle sessioni; considerare la sincronizzazione LDP-IGP per prevenire il blackholing durante la convergenza.
Ambito del control-plane dei router P
- I router P del core non contengono rotte VPN; eseguono solo l’underlay (IGP) e la segnalazione delle label (LDP o RSVP-TE). RSVP-TE può essere usato al posto di, o insieme a, LDP per fare traffic engineering.
Percorso del data-plane
- Il PE di ingresso aggiunge (push) le label VPN e di trasporto; i router P scambiano (swap) solo la label esterna; il penultimo router P rimuove (pop) la label di trasporto (a meno che non sia in uso l’explicit-null); il PE di uscita rimuove (pop) la label VPN, seleziona la VRF e inoltra il pacchetto tramite un normale lookup IP.
Comandi di abilitazione pratica (IOS/IOS XE)
- Sulle interfacce rivolte al core:
undefined
- Globalmente:
undefined
- Verifica:
undefined
,
undefined
,
undefined
Architettura L3VPN: Ruoli, VRF, RD, RT e MP-BGP
Ruoli e demarcazioni
- CE (Customer Edge): esegue un protocollo verso il PE (statico, eBGP, OSPF, EIGRP) e contiene le rotte del cliente; non è a conoscenza di MPLS.
- PE (Provider Edge): gestisce le VRF per ogni tenant, partecipa a MP-BGP (VPNv4/VPNv6) e impone/rimuove le label.
- P (Provider Core): si occupa solo di label-switching; non ha stato delle VRF.
- Cliente: proprietario amministrativo del CE e delle policy di routing del tenant.
VRF e sovrapposizione di indirizzi
- Ogni tenant ottiene una VRF (RIB/FIB separata). È permessa la sovrapposizione degli spazi di indirizzi IPv4/IPv6 tra tenant diversi.
- I Route Distinguisher (RD) rendono le rotte di ogni VRF globalmente uniche anteponendo “RD:” al prefisso per formare NLRI VPNv4/VPNv6; gli RD non sono un meccanismo di sicurezza e non controllano le policy.
- I Route Target (RT) sono BGP extended community usate per etichettare le rotte in esportazione e per selezionare quali rotte una VRF deve importare. La policy basata su RT è il controllo autorevole di importazione/esportazione.
Address family di MP-BGP
- VPNv4: AFI 1, SAFI 128. L’attributo MP_REACH_NLRI trasporta il next hop e una label VPN per ogni rotta. Le rotte VPNv4 sono distribuite solo tra i nodi PE (e i route reflector).
- VPNv6 (6VPE): AFI 2, SAFI 128. Abilita le VPN IPv6 su un core MPLS IPv4. Il next hop BGP può rimanere IPv4; il PE assegna le label VPN per ogni rotta IPv6.
- Abilitare le extended community sulle sessioni BGP tra PE in modo che gli RT vengano trasportati.
Schema di configurazione semplificato (PE)
Definizione della VRF e della connessione al CE:
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
MP-BGP per VPNv4:
undefined
undefined
undefined
undefined
undefined
undefined
undefined
Address family per VRF:
undefined
undefined
-
undefined
undefined
Per 6VPE:
undefined
undefined
undefined
Verifica
undefined
undefined
undefined
undefined
Policy, Route Leaking, Servizi Condivisi e Segmentazione
Policy di import/export degli RT
- Export: contrassegna le route di una VRF con uno o più RT. Import: una VRF importa qualsiasi route il cui RT corrisponda alla sua lista di importazione.
- Un controllo granulare si ottiene con route-map per singola VRF (mappe di export/import) che effettuano il matching dei prefissi e impostano/manipolano gli RT. Questo limita la propagazione involontaria delle route.
Metodi di route leaking
- Leaking basato su RT (consigliato): definire una VRF per i Servizi Condivisi (Shared-Services VRF), esportare i prefissi dei servizi con l’RT SVC e importare l’RT SVC nelle VRF dei tenant selezionati. Utilizzare mappe di export sui tenant per limitare quali route del tenant vengono riesportate verso i servizi.
- Leaking locale da VRF a VRF: su alcune piattaforme, le route statiche possono puntare a interfacce in altre VRF, o il BGP può stabilire peering tra VRF sullo stesso PE. Da usare con cautela; questo metodo bypassa la policy degli RT e può essere più difficile da sottoporre ad audit.
- Compromessi di sicurezza:
- Importazioni eccessivamente permissive portano a una raggiungibilità any-to-any e a potenziali movimenti laterali (lateral movement).
- Il leaking simmetrico senza filtri può creare loop di feedback o esporre prefissi di gestione/infrastruttura.
- Preferire un modello di servizi condivisi hub-and-spoke con liste di autorizzazione esplicite (route-map) e interblocchi a livello di firewall.
Concetti di routing segmentato e migrazione
- La segmentazione enterprise inizia con VRF-Lite all’interno di campus e data center. MPLS L3VPN estende tali segmenti attraverso la WAN senza NAT, preservando gli IP sovrapposti.
- Approccio alla migrazione:
- Mappare ogni segmento VRF-Lite on-premise a una coppia di RT del provider.
- Utilizzare il routing CE-PE (eBGP è preferibile) per scambiare le route per segmento in modo deterministico.
- Introdurre una VRF per i Servizi Condivisi (Shared-Services VRF) per l’egress di DNS/AD/Internet e importarla selettivamente.
- Underlay pronti per il futuro:
- Gli LSP basati su LDP o RSVP-TE sono ampiamente diffusi. Il Segment Routing MPLS (SR-MPLS) può sostituire LDP/RSVP nell’underlay mantenendo identico il modello di servizio L3VPN; solo la label di trasporto proviene da SR anziché da LDP/RSVP.
Operazioni: Control Plane, Data Plane, Verifica e Isolamento dei Guasti
Flusso dei pacchetti end-to-end
- Il CE annuncia un prefisso al PE di ingresso nella VRF X.
- Il PE di ingresso lo installa nella RIB/CEF della VRF X, lo etichetta con gli RT di export, crea un NLRI VPNv4/v6 (RD:prefisso) e assegna un’etichetta VPN.
- MP-BGP annuncia la rotta ai PE remoti (o tramite route reflector), trasportando il next hop (loopback del PE di ingresso) e l’etichetta VPN.
- L’IGP e LDP/RSVP stabiliscono un LSP di trasporto verso il next hop del PE di uscita.
- Data plane: il PE di ingresso inserisce (push) l’etichetta VPN (interna) e l’etichetta di trasporto (esterna); i router P scambiano (swap) le etichette esterne; il penultimo P rimuove (pop) l’etichetta esterna (PHP); il PE di uscita usa l’etichetta interna per selezionare la VRF e inoltra al CE di uscita.
Modalità di guasto comuni e compromessi
- Raggiungibilità dell’underlay o LDP non attivo: MP-BGP potrebbe rimanere attivo, ma senza un LSP di trasporto il PE di ingresso non può inserire un’etichetta esterna valida; i pacchetti vengono scartati. Usare la sincronizzazione LDP-IGP per prevenire il blackholing.
- Etichetta VPN mancante: la rotta VPNv4 è presente ma senza etichetta (o con etichetta 3 con semantica inattesa) interrompe l’inoltro. Verificare che il PE di uscita assegni le etichette per ogni VRF; controllare le policy che potrebbero sopprimere l’annuncio dell’etichetta.
- Mancata corrispondenza degli RT: le rotte sono presenti nella VRF di invio ma non importate dal ricevitore. Verificare gli RT e che le extended community vengano scambiate (send-community extended).
- MTU/frammentazione: gli stack di etichette aggiungono overhead. Assicurarsi che le interfacce del core e dei PE supportino un MTU MPLS sufficiente per evitare scarti; regolare l’MSS se necessario.
- QoS e PHP: la mappatura EXP-to-QoS può essere persa in uscita se l’etichetta superiore viene rimossa (pop). Usare explicit-null per la trasparenza della QoS sull’hop di uscita.
- Selezione del percorso iBGP in VPNv4: senza
maximum-paths ibgp N, potrebbe essere usato un solo percorso anche con ECMP nel core; abilitare il multipath per il bilanciamento del carico.
Flusso di lavoro per la verifica
- Edge CE–PE:
undefined
,
undefined
, o
undefined
- MP-BGP:
undefined
;
undefined
- Etichette:
undefined
;
undefined
;
undefined
- Data plane:
undefined
;
undefined
o verso il loopback del PE di uscita; validare la marcatura EXP/TC se la QoS è in ambito
Stato di salute: considerare BFD sulle adiacenze CE–PE e PE–PE per proteggere le sessioni di routing.
Isolamento dei guasti tra CE, PE e core del provider
- Validare l’adiacenza CE–PE e che le rotte VRF esistano sul PE di ingresso.
- Confermare che la rotta sia esportata in VPNv4 con un RT atteso e un’etichetta VPN presente sul PE di uscita.
- Assicurarsi che esista un LSP di trasporto dall’ingresso all’uscita del PE (vicini LDP/RSVP e etichetta verso il loopback del PE di uscita).
- Testare la raggiungibilità PE–PE usando ping/traceroute con origine dal loopback del PE; verificare la coerenza dell’ECMP.
- Sul PE di uscita, controllare che l’etichetta VPN risolva nella VRF e nell’interfaccia CE corrette.
- Se tutti i controlli del control plane hanno successo, acquisire i contatori del data plane e verificare il comportamento di MTU e QoS.
Scenario di Problema Pratico
Contoso Manufacturing pianifica di migrare da una WAN VRF-Lite a un MPLS L3VPN di un provider, introducendo al contempo una VRF centrale per i Servizi Condivisi (Shared-Services) per Internet e DNS. I tenant A e B usano entrambi internamente 10.10.0.0/16 e devono rimanere isolati, ad eccezione dell’accesso selettivo ai Servizi Condivisi.
Approccio
- Definire le VRF e la policy degli RT sui PE
Configurazione:
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
- Motivazione: Gli RD garantiscono l’unicità tra le rotte 10.10.0.0/16 sovrapposte. Gli RT definiscono i confini di segmentazione. Un RT distinto per i Servizi Condivisi fornisce un hub controllabile.
- Collegare le interfacce CE alle VRF corrette e attivare il routing CE–PE
Esempio di configurazione:
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
- Motivazione: L’eBGP CE–PE fornisce chiari confini di policy e controllo per-tenant senza far trapelare attributi tra i tenant.
- Abilitare MP-BGP tra i PE e propagare RT ed etichette VPN
Configurazione:
undefined
undefined
undefined
undefined
undefined
undefined
undefined
- Motivazione: L’annuncio VPNv4 trasporta sia gli RT che le etichette VPN per-rotta; abilitare il multipath iBGP prepara per l’ECMP su più percorsi RR/PE.
- Costruire e verificare gli LSP di trasporto nel core
Configurazione:
undefined
-
undefined
undefined
undefined
- Motivazione: LDP crea LSP PE-to-PE per l’etichetta esterna. L’ECMP nell’IGP più LDP supporta la scalabilità e la convergenza. Verificare con
undefined
e
undefined
.
- Implementare il “leaking” selettivo dei Servizi Condivisi
Configurazione (sui tenant):
undefined
undefined
-
undefined
undefined
-
undefined
undefined
undefined
undefined
-
undefined
undefined
-
undefined
- Motivazione: I tenant importano solo le rotte dei Servizi Condivisi; i Servizi Condivisi importano le rotte dei tenant ma esportano indietro solo i prefissi approvati per impedire ai tenant di apprendere le rotte degli altri attraverso l’hub.
- Validare i control/data plane e MTU/QoS
Comandi:
undefined
-
undefined
-
undefined
-
undefined
-
undefined
- Motivazione: Conferma il routing VRF, i binding delle etichette e la raggiungibilità end-to-end. Controllare gli MTU delle interfacce per accomodare lo stack di etichette e preservare le marcature QoS; abilitare explicit-null se l’uscita necessita di visibilità sull’EXP.
- Introdurre VPN IPv6 usando 6VPE
Configurazione:
undefined
undefined
undefined
-
undefined
undefined
- Motivazione: Fornisce segmentazione IPv6 attraverso lo stesso core MPLS IPv4 con etichette VPN per-rotta e lo stesso modello di policy basato su RT.
Questo piano a fasi preserva la segmentazione, abilita l’accesso condiviso controllato, scala tramite lo label switching nel core e fornisce chiari punti di verifica per un rapido isolamento dei guasti.
← Ridistribuzione delle Route e Routing Basato su Policy · Tutti i domini · Routing e Distribuzione Multicast →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →