7. Come i PE apprendono le route dai CE

7. Come i PE apprendono le route dai CE (How PEs Learn Routes from CEs)

Un router PE collegato a un particolare VPN deve, per ciascun circuito di attacco che conduce a quel VPN, conoscere quali indirizzi di quel VPN siano raggiungibili tramite quel circuito.

Il PE usa il distintore di route (RD) configurato per convertire tali indirizzi in indirizzi VPN-IPv4. Il PE usa poi tali route VPN-IPv4 come input per BGP. Le route di un sito VPN non vengono fatte trapelare (leak) nell'IGP del backbone.

Quali tecniche di distribuzione PE/CE siano possibili dipende dal fatto che un particolare CE si trovi in un "VPN di transito" (transit VPN). Per "VPN di transito" si intende un VPN contenente un router che riceve route da un "terzo" (cioè da un router che non è in quel VPN e non è nemmeno un router PE) e le ridistribuisce verso un router PE. Un VPN che non è un VPN di transito è un "VPN stub" (stub VPN). La grande maggioranza dei VPN (comprese quasi tutte le reti aziendali) rientra in questo senso nello "stub".

Le tecniche di distribuzione PE/CE possibili sono:

1. Può essere usato l'instradamento statico (static routing, cioè la configurazione). (Ciò è probabilmente utile solo in un VPN stub.)

2. I router PE e CE possono essere peer del protocollo RIP (Routing Information Protocol) [RIP], e il CE può usare RIP per informare il router PE dell'insieme dei prefissi di indirizzo (address prefix) raggiungibili sul suo sito. Configurando RIP sul CE, si deve prestare attenzione a che i prefissi di indirizzo provenienti da altri siti (cioè quelli che il router CE ha appreso dal router PE) non vengano mai annunciati (advertise) di nuovo al PE. Più precisamente: se un router PE (diciamo PE1) riceve una route VPN-IPv4 R1 e di conseguenza distribuisce una route IPv4 R2 a un CE, allora R2 non deve mai essere distribuita dal sito di quel CE verso un router PE (diciamo PE2, dove PE1 e PE2 possono essere lo stesso o diversi router), a meno che PE2 non mappi R2 in una route VPN-IPv4 diversa da R1 (cioè con RD diverso).

3. I router PE e CE possono essere peer OSPF (Open Shortest Path First). Un router PE che è peer OSPF di un router CE appare, dal punto di vista di quel CE, come un router di area 0 (area 0). Se un router PE è peer OSPF di router CE situati in diversi VPN, tale PE deve ovviamente eseguire molteplici istanze (instance) di OSPF.

   Le route IPv4 che un PE apprende da un CE tramite OSPF vengono ridistribuite come route VPN-IPv4 in BGP. L'attributo community estesa (Extended Community) è usato per trasportare con la route tutte le informazioni necessarie affinché la route possa essere distribuita con il tipo di LSA OSPF (Link State Advertisement) appropriato agli altri router CE del VPN. Il tagging delle route OSPF (route tagging) è usato per garantire che le route ricevute dal backbone MPLS/BGP non vengano rispedite nel backbone.

   La procedura completa per l'uso di OSPF tra PE e CE si trova in [VPN-OSPF] e [OSPF-2547-DNBIT].

4. I router PE e CE possono essere peer BGP, e il router CE può usare BGP (in particolare EBGP) per informare il router PE dell'insieme dei prefissi di indirizzo sul suo sito. (Questa tecnica può essere usata in un VPN stub o di transito.)

   Rispetto alle altre tecniche, questa presenta molteplici vantaggi:

   a) A differenza degli approcci IGP, ciò non richiede che il PE esegua molteplici istanze di algoritmi di instradamento per comunicare con molteplici CE.

   b) BGP è progettato proprio per questo: trasmettere informazioni di instradamento tra sistemi che operano in domini amministrativi diversi.

   c) Se il sito contiene una "BGP backdoor", cioè un router avente una connessione BGP con un router esterno al router PE, la procedura funziona correttamente in tutti i casi. Le altre procedure possono funzionare o meno, a seconda dei casi.

   d) L'uso di BGP consente al CE di trasmettere facilmente attributi della route al PE. Un insieme completo di attributi e il loro uso non rientrano nell'ambito di questo documento. Alcuni esempi di tale uso:

   -   Il CE può suggerire una particolare destinazione di route (Route Target) per ciascuna route, tra l'insieme delle destinazioni che il PE è autorizzato ad agganciare alla route. Il PE aggancerà allora solo la destinazione suggerita, anziché l'intero insieme. Ciò dà all'amministratore del CE un certo controllo dinamico sulla distribuzione delle route dal CE.
   
   -   Possono essere definiti altri tipi di attributi community estese, con l'intento che questi siano trasportati in modo trasparente (cioè senza modifica da parte del router PE) dal CE al CE. Ciò consentirebbe all'amministratore del CE di realizzare un filtraggio delle route aggiuntivo, oltre a quello effettuato dal PE, senza coordinamento con il SP.

   D'altra parte, l'uso di BGP può essere una novità per l'amministratore del CE.

   Se un sito non è in un VPN di transito, notare che non ha bisogno di un numero di sistema autonomo (ASN) univoco. Ciascun CE di un sito non di transito può usare lo stesso ASN. Esso può essere scelto nello spazio ASN privato e sarà rimosso (strip) dal PE. I loop di instradamento (routing loop) sono evitati tramite l'uso dell'attributo Site of Origin.

   Che succede se un insieme di siti costituisce un VPN di transito? In generale, ciò avviene solo se tale VPN è esso stesso la rete di un Internet Service Provider (ISP), che a sua volta acquisisce servizi di backbone da un altro SP. Quest'ultimo può essere chiamato "carrier's carrier". In tal caso, il modo migliore per fornire tale VPN è fare in modo che i router CE supportino MPLS e usino la tecnica descritta nella sezione 9.

Quando non abbiamo bisogno di distinguere i diversi modi in cui un PE apprende l'esistenza dei prefissi di indirizzo presenti su un dato sito, diremo semplicemente che il PE ha "appreso" (learn) tali route da quel sito. Ciò include il caso in cui il PE sia stato configurato manualmente con tali route.

Prima che un PE possa ridistribuire una route VPN-IPv4 che ha appreso da un sito, deve assegnarle un attributo Route Target (vedere sezione 4.3.1), e può assegnarle un attributo Site of Origin.

L'attributo Site of Origin (se usato) è codificato come community estesa Route Origin [BGP-EXTCOMM]. Lo scopo di questo attributo è identificare univocamente l'insieme delle route apprese da un particolare sito. In alcuni casi ciò è necessario per garantire che una route appresa da un particolare sito tramite un determinato circuito PE/CE non venga ridistribuita verso quel sito tramite un altro circuito PE/CE. Ciò è particolarmente utile se BGP è usato come protocollo PE/CE ma i diversi siti non hanno ancora ricevuto ASN distinti.