4. Distribuzione delle route VPN tramite BGP

4. Distribuzione delle route VPN tramite BGP (VPN Route Distribution via BGP)

I router PE usano BGP per distribuire le route VPN tra loro (più precisamente, per rendere possibile che le route VPN siano distribuite tra loro).

Consentiamo a ciascun VPN di avere il proprio spazio di indirizzamento (address space), il che significa che un dato indirizzo può fare riferimento a sistemi diversi in VPN diversi. Se due route verso uno stesso prefisso (prefix) di indirizzo IP sono in realtà route verso sistemi diversi, è importante che BGP non le tratti come route confrontabili; altrimenti, BGP potrebbe installarne solo una, rendendo l'altro sistema irraggiungibile. Inoltre, dobbiamo assicurarci che la politica (policy) sia usata per decidere quali pacchetti vengano inviati su quali route — dopo che BGP ne ha installate diverse, solo una di tali route può apparire in un dato VRF.

Raggiungiamo questi obiettivi usando una nuova famiglia di indirizzi (address family), come di seguito descritto.

4.1. La famiglia di indirizzi VPN-IPv4 (The VPN-IPv4 Address Family)

Le estensioni multiprotocollo di BGP [BGP-MP] consentono a BGP di trasportare route da molteplici "famiglie di indirizzi". Introduciamo il concetto di "famiglia di indirizzi VPN-IPv4". Un indirizzo VPN-IPv4 è una quantità di 12 byte, che inizia con un distintore di route (Route Distinguisher, RD) di 8 byte, seguito da un indirizzo IPv4 di 4 byte. Se diversi VPN usano lo stesso prefisso di indirizzo IPv4, i PE convertono tali prefissi in prefissi di indirizzo VPN-IPv4 univoci. Ciò garantisce che, anche se un medesimo indirizzo è usato in diversi VPN, BGP possa trasportare molteplici route del tutto distinte verso tale indirizzo, una per ciascun VPN.

Poiché gli indirizzi VPN-IPv4 e gli indirizzi IPv4 appartengono a famiglie di indirizzi diverse, BGP non li tratterà mai come indirizzi confrontabili.

Il RD è soltanto un numero; non contiene alcuna informazione intrinseca. Non identifica né l'origine della route né l'insieme dei VPN a cui la route sarà distribuita. L'unico scopo del RD è consentire la creazione di route distinte per un prefisso di indirizzo IPv4 pubblico comune. Per quanto riguarda il luogo in cui ridistribuire la route, occorrono altri mezzi (vedere sezione 4.3).

Il RD può anche essere usato per creare molteplici route distinte verso uno stesso sistema. Abbiamo discusso il caso in cui la route verso un determinato server (server) dovrebbe essere diversa per il traffico di intranet e per quello di extranet. Ciò può essere realizzato creando due route VPN-IPv4 aventi la stessa parte IPv4 ma RD diversi. Ciò consente a BGP di installare molteplici route distinte verso uno stesso sistema, e di usare la politica (vedere sezione 4.3.5) per decidere quali pacchetti usino quale route.

La struttura del RD è concepita in modo che ciascun fornitore di servizi possa gestire il proprio spazio di numerazione (numbering space, cioè assegnare i propri RD) senza entrare in conflitto con le assegnazioni di RD fatte da altri fornitori. Un RD è composto da tre campi: un campo tipo (type) di 2 byte, un campo amministratore (administrator) e un campo numero assegnato (assigned number). Il valore del campo tipo determina la lunghezza degli altri due campi, nonché la semantica del campo amministratore. Il campo amministratore identifica un'autorità (authority) che ha assegnato il numero, e il campo numero assegnato contiene un numero assegnato da tale autorità per uno scopo particolare. Ad esempio, un RD può avere un campo amministratore contenente un numero di sistema autonomo (Autonomous System number, ASN), e un (altro) campo di 4 byte contenente un numero appartenente allo spazio di numerazione gestito dal SP a cui l'ASN è stato assegnato.

La ragione d'essere di questa struttura di RD è garantire che un SP che fornisce il servizio di backbone VPN possa sempre creare un RD univoco quando necessario. Tuttavia, tale struttura non ha alcun significato per BGP — quando BGP confronta questi due prefissi di indirizzo, ignora totalmente la struttura.

I PE devono essere configurati in modo che le route verso un particolare CE siano associate a un particolare RD. Tale configurazione può comportare che tutte le route verso un particolare CE siano associate allo stesso RD, oppure che route diverse siano associate a RD diversi, anche se conducono allo stesso CE.

4.2. Codifica dei distintori di route (Encoding of Route Distinguishers)

Come già detto, un indirizzo VPN-IPv4 è composto da un distintore di route di 8 byte seguito da un indirizzo IPv4 di 4 byte. La codifica del RD è la seguente:

Campo tipo (Type Field): 2 byte
Campo valore (Value Field): 6 byte

L'interpretazione del campo valore dipende dal valore del campo tipo. Sono attualmente definiti tre valori del campo tipo: 0, 1 e 2.

Tipo 0: il campo valore è composto da due sottocampi:
- Sottocampo amministratore (Administrator subfield): 2 byte
- Sottocampo numero assegnato (Assigned Number subfield): 4 byte
Il sottocampo amministratore deve contenere un numero di sistema autonomo. Se tale ASN proviene dallo spazio ASN pubblico, deve essere stato assegnato dall'autorità competente (l'uso di valori ASN dello spazio privato è fortemente sconsigliato). Il sottocampo numero assegnato contiene un numero dello spazio di numerazione gestito dall'impresa a cui l'ASN è stato assegnato.
Tipo 1: il campo valore è composto da due sottocampi:
- Sottocampo amministratore: 4 byte
- Sottocampo numero assegnato: 2 byte
Il sottocampo amministratore deve contenere un indirizzo IP. Se tale indirizzo IP proviene dallo spazio di indirizzamento IP pubblico, deve essere stato assegnato dall'autorità competente (l'uso di indirizzi dello spazio privato è fortemente sconsigliato). Il sottocampo numero assegnato contiene un numero dello spazio di numerazione gestito dall'impresa a cui l'indirizzo IP è stato assegnato.
Tipo 2: il campo valore è composto da due sottocampi:
- Sottocampo amministratore: 4 byte
- Sottocampo numero assegnato: 2 byte
Il sottocampo amministratore deve contenere un numero di sistema autonomo di 4 byte (Autonomous System number) [BGP-AS4]. Se tale ASN proviene dallo spazio ASN pubblico, deve essere stato assegnato dall'autorità competente (l'uso di valori ASN dello spazio privato è fortemente sconsigliato). Il sottocampo numero assegnato contiene un numero dello spazio di numerazione gestito dall'impresa a cui l'ASN è stato assegnato.

4.3. Controllo della distribuzione delle route (Controlling Route Distribution)

In questa sezione, discutiamo come controllare la distribuzione delle route VPN-IPv4.

Se un router PE è "agganciato" a un dato VPN tramite la sua connessione a un particolare CE di quel VPN, apprenderà alcune route IP di quel VPN dal router CE corrispondente. Le route apprese da un particolare router CE tramite un determinato circuito di attacco possono essere installate nel VRF associato a quel circuito di attacco. Quali di tali route vengano così installate dipende dal modo in cui il PE apprende le route dal CE. In particolare, quando PE e CE sono peer del protocollo di instradamento (routing protocol), ciò è determinato dal processo decisionale (decision process) di tale protocollo di instradamento, come discusso nella sezione 7.

Tali route vengono poi convertite in route VPN-IPv4 ed "esportate" (export) verso BGP. Se esistono molteplici route verso un dato prefisso di indirizzo VPN-IPv4, BGP userà il suo processo decisionale per selezionarne una sola, la "migliore" (best). Tale route viene poi distribuita da BGP agli altri PE che ne hanno bisogno. Presso questi altri PE, BGP selezionerà nuovamente la migliore route VPN-IPv4 per un dato prefisso di indirizzo VPN-IPv4. La route VPN-IPv4 selezionata viene quindi riconvertita in route IP e "importata" (import) in uno o più VRF. Che venga effettivamente installata nel VRF dipende dal risultato dei processi decisionali BGP e del protocollo usato tra PE e CE. Infine, qualsiasi route installata in un VRF può essere distribuita ai router CE associati.

4.3.1. L'attributo Route Target (The Route Target Attribute)

Ciascun VRF è associato a uno o più attributi Route Target (RT).

Quando un router PE crea una route VPN-IPv4 a partire da una route IPv4 appresa da un CE, la route viene associata a uno o più attributi Route Target. Tali attributi sono trasportati da BGP come attributi della route.

Qualsiasi route associata alla destinazione di route T deve essere distribuita a ciascun router PE che possiede un VRF associato alla destinazione di route T. Quando un router PE riceve tale route, essa è idonea (eligible) a essere installata nei VRF di quel PE associati alla destinazione di route T. (Viene effettivamente installata solo se il risultato dei processi decisionali BGP e IGP lo consente.)

Un attributo Route Target può essere considerato identificativo di un insieme di siti (sebbene, più precisamente, si dovrebbe considerarlo identificativo di un insieme di VRF). Associare un particolare attributo Route Target a una route rende tale route idonea a essere inserita nei VRF usati per inoltrare il traffico dai siti corrispondenti.

Esiste un insieme di destinazioni di route che i router PE agganciano alle route apprese da un sito S; chiamiamole "destinazioni di esportazione" (Export Targets). Esiste inoltre un insieme di destinazioni di route che il PE usa per decidere se una route ricevuta da un altro PE possa essere inserita nel VRF associato al sito S; chiamiamole "destinazioni di importazione" (Import Targets). Questi due insiemi sono distinti e non necessariamente identici. Notare che una data route VPN-IPv4 è idonea a essere installata in un particolare VRF solo se esiste una destinazione di route che è sia una delle destinazioni di route della route che una delle destinazioni di importazione di quel VRF.

La funzione svolta dall'attributo Route Target è simile a quella svolta dall'attributo BGP Communities. Tuttavia, il formato di quest'ultimo è inadeguato per l'uso presente, poiché consente solo uno spazio di numerazione di 2 byte. Prevediamo di strutturare il formato come descritto per il RD (vedere sezione 4.2), in modo che un campo tipo definisca la lunghezza del campo amministratore e il resto dell'attributo provenga dallo spazio di numerazione dell'amministratore specificato. Ciò può essere realizzato usando le community estese BGP (BGP Extended Communities). Le destinazioni di route qui discusse sono codificate come community estese BGP Route Target [BGP-EXTCOMM], e hanno una struttura simile a quella del RD.

Quando un parlante (speaker) BGP riceve molteplici route verso uno stesso prefisso VPN-IPv4, vengono usate le regole di preferenza di route (route preference) di BGP per selezionare la route VPN-IPv4 da installare.

Notare che una route può avere un solo RD, ma molteplici destinazioni di route. In BGP, l'uso di una singola route con molteplici attributi (anziché di molteplici route) migliora la scalabilità (scalability). Si potrebbe eliminare l'attributo Route Target creando più route (cioè usando più RD), ma ciò peggiorerebbe la scalabilità.

Come decide il PE quali attributi Route Target associare a una data route? Vi sono molteplici possibilità. Il PE può essere configurato per associare tutte le route verso un dato sito a una determinata destinazione di route. In alternativa, il PE può essere configurato per associare alcune route verso un dato sito a una destinazione di route, e altre a un'altra destinazione di route.

Se PE e CE sono essi stessi peer BGP (vedere sezione 7), il SP può, entro certi limiti, consentire al cliente di specificare come le sue route siano distribuite. Il SP e il cliente devono concordare in anticipo l'insieme delle RT che il cliente è autorizzato ad agganciare alle route del suo VPN. Il CE può quindi agganciare una o più di tali RT a ciascuna delle route IP che distribuisce al PE. Ciò consente al cliente di specificare in tempo reale, entro limiti concordati, la propria politica di distribuzione delle route. Se al CE è consentito agganciare RT alle sue route, il PE deve filtrare tutte le route contenenti RT che il cliente non è autorizzato a usare. In caso contrario, il PE deve rimuovere la RT prima di convertire la route del cliente in route VPN-IPv4.

4.3.2. Distribuzione delle route tra PE tramite BGP (Route Distribution Among PEs by BGP)

Se due siti di un VPN sono collegati a PE situati nello stesso sistema autonomo (Autonomous System), tali PE possono scambiarsi reciprocamente le route VPN-IPv4 tramite le loro connessioni IBGP. ("IBGP" indica l'insieme di protocolli e procedure usati su una connessione BGP quando entrambi i parlanti BGP sono nello stesso sistema autonomo. Ciò si distingue da "EBGP" — l'insieme di procedure usate tra due parlanti BGP in sistemi autonomi diversi.) In alternativa, ciascun PE può stabilire una connessione IBGP con un riflettore di route (route reflector) [BGP-RR].

Quando un router PE distribuisce una route VPN-IPv4 tramite BGP, usa il proprio indirizzo come "BGP next hop" (BGP next hop). Tale indirizzo è codificato come un indirizzo VPN-IPv4 il cui RD è 0. ([BGP-MP] richiede che l'indirizzo del next hop appartenga alla stessa famiglia di indirizzi della NLRI.) Assegna inoltre e distribuisce un'etichetta (label) MPLS. (Sostanzialmente, il router PE distribuisce non una route VPN-IPv4, ma una "route VPN-IPv4 con etichetta" — Labeled VPN-IPv4 route. Vedere [MPLS-BGP].) Quando un PE elabora un pacchetto ricevuto con tale etichetta in cima allo stack, il PE estrae (pop) lo stack e tratta il pacchetto in modo appropriato.

Questo PE può distribuire l'esatto insieme delle route presenti nel VRF, oppure può eseguire una sintesi (summarization) e distribuire un aggregato (aggregate) di tali route, o una combinazione dei due.

Supponiamo che un PE abbia assegnato un'etichetta L per la route R e ne abbia distribuito l'associazione tramite BGP. Se R è un aggregato di un insieme di route nel VRF, allora tale PE sa che i pacchetti in arrivo dal backbone recanti tale etichetta devono avere il loro indirizzo di destinazione cercato in un VRF. Quando il PE cerca tale etichetta nella sua base di informazioni sulle etichette (Label Information Base), apprende quale VRF usare. D'altra parte, se R non è un aggregato, cercando l'etichetta il PE apprende il circuito di colloquio di uscita (egress attachment circuit) e l'header di incapsulamento del pacchetto. In questo caso, non viene effettuata alcuna ricerca in un VRF.

Prevediamo che il caso più comune sia quello in cui la route non è un aggregato. Tuttavia, l'aggregato è molto utile quando il VRF contiene molte route di host (host route, ad esempio in caso di accesso telefonico — dial-in), o quando il VRF è associato a un'interfaccia di rete locale (Local Area Network, LAN) (dove ciascun sistema sulla LAN ha un header di livello 2 di uscita diverso, ma non si distribuisce una route distinta per ciascuno di tali sistemi).

Il fatto che ciascuna route abbia la propria etichetta è una scelta di implementazione. Vi sono molteplici algoritmi possibili per decidere se due route ricevano la stessa etichetta:

Si può scegliere di far condividere a tutto il VRF un'unica etichetta, cosicché tutte le route di quel VRF condividano la stessa etichetta. Così, quando il PE di uscita riceve un pacchetto recante tale etichetta, deve cercare l'indirizzo di destinazione IP del pacchetto in quel VRF (il "VRF di uscita" del pacchetto) per determinare il circuito di uscita e la relativa incapsulazione di collegamento dati (data link).
Si può scegliere di far condividere a ciascun circuito di attacco un'unica etichetta, cosicché tutte le route aventi lo stesso "circuito di attacco di uscita" condividano la stessa etichetta. Ciò consente di evitare una ricerca nel VRF di uscita, benché possa ancora essere necessaria una ricerca (ad esempio ARP) per determinare l'incapsulamento di collegamento dati.
Si può scegliere di dare a ciascuna route un'etichetta indipendente. Così, se una route può essere raggiunta tramite uno di molteplici circuiti di attacco, l'instradamento PE/CE può commutare il percorso preferito della route da un circuito a un altro senza dover distribuire una nuova etichetta per tale route.

Altri algoritmi sono possibili. La scelta dell'algoritmo è lasciata alla discrezione del PE di uscita; è altrimenti trasparente.

Usando le etichette MPLS distribuite tramite BGP in questo modo, presupponiamo che un pacchetto MPLS recante tale etichetta possa essere tunnelizzato (tunnel) dal router che ha installato la corrispondente route BGP verso il router che è il BGP next hop di tale route. Ciò richiede o un percorso di commutazione delle etichette (label switched path) tra questi due router, o la possibilità di usare un'altra tecnologia di tunnel (ad esempio [MPLS-in-IP-GRE]).

Il tunnel può seguire un instradamento "best effort", o un instradamento con ingegneria del traffico (traffic-engineered). Tra una data coppia di router può esserci un tale tunnel, o molteplici, forse con diverse caratteristiche di qualità del servizio (Quality of Service, QoS). Per l'architettura VPN, l'essenziale è che esista tale tunnel. Per garantire l'interoperabilità (interoperability) tra i sistemi che implementano questa architettura VPN usando percorsi di commutazione delle etichette MPLS come tecnologia di tunnel, tutti questi sistemi devono supportare il protocollo di distribuzione delle etichette (Label Distribution Protocol, LDP) [MPLS-LDP]. In particolare, sulla maggior parte delle interfacce deve essere supportata la modalità downstream non sollecitato (Downstream Unsolicited); sulle interfacce LC-ATM [MPLS-ATM] e LC-FR [MPLS-FR] deve essere supportata la modalità downstream on demand (Downstream on Demand).

Se il tunnel segue un instradamento best effort, il PE trova la route verso l'endpoint remoto (remote endpoint) cercando il suo indirizzo IP nella tabella di inoltro predefinita.

Un router PE, a meno che non sia un riflettore di route (vedere sezione 4.3.3) o un ASBR (Autonomous System Border Router) di un VPN multi-fornitore (vedere sezione 10), non deve installare una route VPN-IPv4 a meno che non abbia almeno un VRF la cui destinazione di importazione sia identica a uno degli attributi Route Target della route. Si deve usare un filtraggio in ingresso (inbound filtering) per scartare tali route. Se in seguito a un VRF viene aggiunta una nuova destinazione di importazione (un'operazione "Join VPN"), quel PE deve poi acquisire le route che avrebbe potuto scartare in precedenza. Ciò può essere realizzato usando il meccanismo di aggiornamento (refresh) descritto in [BGP-RFSH]. Anche il meccanismo di filtraggio delle route in uscita (outbound route filtering) di [BGP-ORF] può essere usato per rendere il filtraggio più dinamico.

Allo stesso modo, se una particolare destinazione di importazione non esiste più in alcun VRF di un PE (a seguito di una o più operazioni "Prune VPN"), quel PE può scartare tutte le route che, di conseguenza, non hanno più alcuna destinazione di importazione di quel PE tra i loro attributi Route Target.

Un router che non è collegato a nessun VPN, e non è un riflettore di route (cioè un router P), non installerà mai alcuna route VPN-IPv4.

Notare che le operazioni di Join e Prune VPN non sono interruttive (non-disruptive), purché sia usato il meccanismo di aggiornamento di [BGP-RFSH]; non è necessario interrompere alcuna connessione BGP.

A causa di queste regole di distribuzione, nessun PE ha necessità di mantenere le route di tutti i VPN supportati; ciò è una considerazione importante di scalabilità.

4.3.3. Uso dei riflettori di route (Use of Route Reflectors)

Anziché stabilire una maglia IBGP (mesh) completa tra i PE, è vantaggioso usare i riflettori di route BGP [BGP-RR] per migliorare la scalabilità. Tutte le tecniche abituali per migliorare la scalabilità con i riflettori di route (ad esempio una gerarchia (hierarchy) di riflettori di route) sono disponibili.

I riflettori di route sono gli unici sistemi che hanno necessità di conoscere le route di VPN a cui non sono direttamente collegati. Tuttavia, non è necessario che un singolo riflettore di route conosca l'insieme di tutte le route VPN-IPv4 di tutti i VPN supportati dal backbone.

Di seguito delineiamo due modi diversi di ripartire l'insieme delle route VPN-IPv4 tra un insieme di riflettori di route.

Ciascun riflettore di route è preconfigurato con un elenco di destinazioni di route. Più riflettori di route possono essere preconfigurati con il medesimo elenco per ridondanza. Il riflettore di route usa l'elenco preconfigurato per costruire il proprio filtraggio delle route in ingresso. Il riflettore di route può usare le tecniche di [BGP-ORF] per installare, su ciascuno dei suoi peer (che sia un altro riflettore di route o un PE), l'insieme di filtri di route in uscita (Outbound Route Filter, ORF) contenente il suo elenco preconfigurato di destinazioni di route. Notare che il riflettore di route dovrebbe accettare gli ORF dagli altri riflettori di route, il che significa che dovrebbe annunciare (advertise) la capacità (capability) ORF agli altri riflettori di route.

Il fornitore di servizi può modificare l'elenco preconfigurato di destinazioni di route su un riflettore di route. Quando lo fa, il riflettore di route modifica gli ORF che ha installato su tutti i suoi peer IBGP. Per ridurre la frequenza delle modifiche di configurazione sui riflettori di route, un blocco (block) di destinazioni di route può essere preconfigurato per ciascun riflettore di route. Così, quando un nuovo VPN richiede una nuova destinazione di route, uno o più riflettori di route hanno già (pre-)configurato tale destinazione di route.

A meno che un dato PE non sia cliente di tutti i riflettori di route, l'aggiunta di un nuovo VPN a quel PE ("Join VPN") richiederà che esso diventi cliente del (o dei) riflettore(i) di route che mantiene le route di quel VPN. Allo stesso modo, la rimozione di un VPN esistente da un PE ("Prune VPN") può portare a una situazione in cui quel PE non ha più bisogno di essere cliente di certi riflettori di route. In entrambi i casi, l'operazione di join o prune non è interruttiva (purché si usi [BGP-RFSH]), e non richiede mai di interrompere una connessione BGP, solo di ristabilirla.

(Con "aggiunta di un nuovo VPN a un PE" intendiamo: aggiunta di una nuova destinazione di importazione a uno dei suoi VRF, o aggiunta di un nuovo VRF la cui destinazione di importazione non è quella di nessun altro VRF di quel PE.)
Un altro approccio consiste nel rendere ciascun PE cliente di un insieme di riflettori di route. Invece di preconfigurare un elenco di destinazioni di route e applicare un filtraggio delle route in ingresso sulle route ricevute dai suoi clienti (PE), il riflettore di route accetta tutte le route da tutti i suoi clienti (PE). Il riflettore di route tiene traccia dell'insieme delle destinazioni di route portate da tutte le route che riceve. Quando riceve da un cliente una route recante una destinazione di route non presente in tale insieme, la destinazione di route viene immediatamente aggiunta all'insieme. D'altra parte, quando non possiede più alcuna route recante una particolare destinazione di route dell'insieme, il riflettore di route dovrebbe ritardare (di diverse ore) la rimozione di tale destinazione di route dall'insieme.

Il riflettore di route usa tale insieme per costruire il filtro delle route in ingresso che applica alle route ricevute da altri riflettori di route. Può inoltre usare gli ORF per installare il filtraggio di uscita appropriato sugli altri riflettori di route. Come per il primo metodo, il riflettore di route dovrebbe accettare gli ORF dagli altri riflettori di route, e dovrebbe quindi annunciare la capacità ORF a questi ultimi.

Quando il riflettore di route modifica tale insieme, deve modificare immediatamente il suo filtraggio delle route in ingresso. Inoltre, se il riflettore di route usa gli ORF, gli ORF devono essere immediatamente modificati per riflettere la variazione dell'insieme. Se il riflettore di route non usa gli ORF e aggiunge una nuova destinazione di route all'insieme, deve emettere un aggiornamento BGP (BGP Refresh) verso gli altri riflettori di route dopo aver modificato il suo filtraggio in ingresso.

Il ritardo di "diverse ore" consente al riflettore di route di conservare route recanti una data destinazione di route, anche se ha perso il suo ultimo cliente interessato a tali route. Ciò evita di dover riacquisire tutte quelle route se la "scomparsa" del cliente fosse solo temporanea.

Con questo processo, le operazioni di Join e Prune VPN sono anch'esse non interruttive.

Notare che questa tecnica non funziona correttamente se un PE cliente ha un VRF la cui destinazione di importazione non è una delle sue destinazioni di esportazione.

In questi processi, un router PE collegato a un particolare VPN "scopre automaticamente" (auto-discover) gli altri PE collegati allo stesso VPN. L'aggiunta di un nuovo router PE, o il collegamento di un PE esistente a un nuovo VPN, non richiede alcuna riconfigurazione degli altri router PE.

Così come nessun router PE ha necessità di conoscere tutte le route VPN-IPv4 supportate dal backbone, queste regole di distribuzione garantiscono che nessun riflettore di route (RR) abbia necessità di conoscere tutte le route VPN-IPv4 supportate. Pertanto, il numero totale di tali route che il backbone può supportare non è limitato dalla capacità di alcun singolo dispositivo, e può quindi crescere quasi illimitatamente.

4.3.4. Come la NLRI VPN-IPv4 è trasportata in BGP (How VPN-IPv4 NLRI Is Carried in BGP)

Le estensioni multiprotocollo di BGP [BGP-MP] sono usate per codificare la NLRI. Se il campo AFI (Address Family Identifier) è impostato a 1 e il campo SAFI (Subsequent Address Family Identifier) a 128, allora la NLRI è un indirizzo VPN-IPv4 con etichetta. L'AFI 1 è usato poiché il protocollo di livello di rete associato a tale NLRI rimane IP. Notare che questa architettura VPN non richiede la capacità di distribuire indirizzi VPN-IPv4 senza etichetta.

Affinché due parlanti BGP possano scambiarsi NLRI VPN-IPv4 con etichetta, devono usare l'annuncio delle capacità (Capabilities Advertisement) di BGP per assicurarsi reciprocamente di poter trattare correttamente tali NLRI. Ciò avviene secondo [BGP-MP], usando il codice di capacità (capability code) 1 (BGP multiprotocollo) con AFI=1 e SAFI=128.

La codifica della NLRI VPN-IPv4 con etichetta è specificata in [MPLS-BGP], dove il prefisso è composto da un RD di 8 byte seguito da un prefisso IPv4.

4.3.5. Costruzione di VPN usando le destinazioni di route (Building VPNs Using Route Targets)

Configurando in modo appropriato le destinazioni di importazione e di esportazione, si possono costruire diversi tipi di VPN.

Supponiamo di voler creare un gruppo di utenti chiuso (closed user group) a maglia completa, cioè un insieme di siti in cui ciascun sito può inviare traffico (traffic) direttamente a qualsiasi altro sito, ma il traffico non può essere né inviato né ricevuto da altri siti. Allora, ciascun sito è associato a un VRF; si sceglie un singolo attributo Route Target, che si designa sia come destinazione di importazione che come destinazione di esportazione per ciascun VRF, e non si designa tale destinazione di route come destinazione di importazione o esportazione per alcun altro VRF.

Un altro caso, supponiamo di voler creare un VPN di tipo "hub and spoke". Ciò può essere fatto usando due valori di destinazione di route, uno a significare "Hub", uno a significare "Spoke". Sul VRF collegato al sito hub, "Hub" è la destinazione di esportazione e "Spoke" è la destinazione di importazione. Sul VRF collegato al sito spoke, "Hub" è la destinazione di importazione e "Spoke" è la destinazione di esportazione.

Così, il metodo di controllo della distribuzione delle informazioni di instradamento tra insiemi di siti è molto flessibile, il che offre a sua volta una grande flessibilità nella costruzione dei VPN.

4.3.6. Distribuzione delle route tra VRF in un singolo PE (Route Distribution Among VRFs in a Single PE)

Anche se due VRF si trovano nello stesso PE, le route possono essere distribuite da un VRF all'altro, benché in tal caso non si possa dire che la route sia distribuita tramite BGP. Tuttavia, la decisione di distribuire una particolare route da un VRF a un altro VRF nello stesso PE è la stessa che se i VRF fossero su PE diversi. Cioè, dipende dall'attributo Route Target assegnato alla route (o da quello che sarebbe stato assegnato se la route fosse stata distribuita tramite BGP), e dalle destinazioni di importazione del secondo VRF.