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

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

Il router PE collegato a una particolare VPN deve sapere, per ogni attachment circuit che porta a quella VPN, quali indirizzi sono raggiungibili attraverso quell'attachment circuit.

Il PE traduce questi indirizzi in indirizzi VPN-IPv4, utilizzando un RD configurato. Il PE tratta quindi queste route VPN-IPv4 come input per BGP. Le route provenienti da un sito VPN non (NOT) vengono divulgate nell'IGP della dorsale.

L'esatta tecnica di distribuzione delle route PE/CE dipenderà dal fatto che un particolare CE si trovi o meno in una "VPN di transito". Una "VPN di transito" è una VPN che contiene un router che riceve route da una "terza parte" (ovvero, un router che non è nella VPN, ma non è un router PE) e ridistribuisce tali route a un router PE. Una VPN che non è una VPN di transito è una "VPN stub". Ci si aspetta che la stragrande maggioranza delle VPN, incluse praticamente tutte le reti aziendali, saranno "stub" in questo senso.

Le possibili tecniche di distribuzione PE/CE sono:

1. Può essere utilizzato il routing statico (cioè la configurazione). (Questo è probabilmente utile solo nelle VPN stub.)

2. I router PE e CE possono essere peer Routing Information Protocol (RIP) [RIP], e il CE può usare RIP per comunicare al router PE l'insieme di prefissi di indirizzo raggiungibili nel sito del router CE. Quando RIP è configurato nel CE, bisogna prestare attenzione affinché i prefissi di indirizzo di altri siti (cioè i prefissi di indirizzo che il router CE ha appreso dal router PE) non vengano mai pubblicizzati 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 essere ridistribuita dal sito di quel CE a un router PE, diciamo PE2 (dove PE1 e PE2 possono essere lo stesso router o router diversi), a meno che PE2 non mappi R2 in una route VPN-IPv4 diversa da R1 (cioè, contenente un RD diverso).

3. I router PE e CE possono essere peer OSPF. Un router PE che è un peer OSPF di un router CE appare al router CE come un router dell'area 0. Se un router PE è un peer OSPF di router CE che si trovano in VPN diverse, il PE deve ovviamente eseguire più istanze di OSPF.

   Le route IPv4 che il PE apprende dal CE via OSPF vengono ridistribuite in BGP come route VPN-IPv4. Gli attributi Extended Community (Comunità estesa) vengono utilizzati per trasportare tutte le informazioni necessarie con la route, in modo che la route possa essere distribuita ad altri router CE nella VPN nel tipo appropriato di OSPF Link State Advertisement (LSA). Il tagging delle route OSPF viene utilizzato per garantire che le route ricevute dalla dorsale MPLS/BGP non vengano rispedite nella dorsale.

   La specifica dell'insieme completo di procedure per l'uso di OSPF tra PE e CE può essere trovata 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 comunicare al router PE l'insieme di prefissi di indirizzo che si trovano nel sito del router CE. (Questa tecnica può essere utilizzata nelle VPN stub o nelle VPN di transito.)

   Questa tecnica presenta una serie di vantaggi rispetto alle altre:

   a) A differenza delle alternative IGP, ciò non richiede che il PE esegua più istanze di algoritmo di routing per parlare con più CE.

   b) BGP è esplicitamente progettato proprio per questa funzione: passare informazioni di routing tra sistemi gestiti da diverse amministrazioni.

   c) Se un sito contiene "BGP backdoor", ovvero router con connessioni BGP a router diversi dai router PE, questa procedura funzionerà correttamente in ogni circostanza. Le altre procedure potrebbero funzionare o meno, a seconda delle circostanze esatte.

   d) L'uso di BGP rende facile per il CE passare attributi delle route al PE. La specifica completa dell'insieme di attributi e del loro utilizzo è al di fuori dello scopo di questo documento. Tuttavia, alcuni esempi di come questo potrebbe essere utilizzato sono i seguenti:

   -   Il CE può suggerire un Route Target (Obiettivo di rotta) specifico per ogni route, da scegliere tra quelli che il PE è autorizzato ad allegare a tale route. Il PE attaccherebbe quindi solo il Route Target suggerito, non l'insieme completo. Ciò conferisce all'amministratore del CE un certo controllo dinamico sulla distribuzione delle route dal CE.
   
   -   Possono essere definiti altri tipi di attributi Extended Community, con l'intento di passare questi attributi in modo trasparente (cioè, senza modifiche da parte dei router PE) da CE a CE. Ciò consentirebbe all'amministratore del CE di implementare un filtro delle route aggiuntivo, al di là di quello che fa il PE. Questo filtro aggiuntivo non richiede coordinamento con l'SP.

   D'altra parte, l'uso di BGP potrebbe essere nuovo per gli amministratori CE.

   Se un sito non si trova in una VPN di transito, si noti che non ha bisogno di avere un Autonomous System Number (Numero di Sistema Autonomo, ASN) univoco. Ogni CE il cui sito non si trova in una VPN di transito può utilizzare lo stesso ASN. Questo può essere scelto dallo spazio ASN privato e verrà rimosso dal PE. I loop di routing vengono prevenuti mediante l'uso dell'attributo Site of Origin (Origine del sito) (vedi sotto).

   E se un insieme di siti costituisce una VPN di transito? Ciò si verificherà generalmente solo se la VPN stessa è la rete di un Internet Service Provider (ISP) e l'ISP sta acquistando a sua volta servizi dorsali da un altro SP. Quest'ultimo SP può essere definito un "carrier's carrier" (vettore del vettore). In tal caso, il modo migliore per fornire la VPN è consentire ai router CE di supportare MPLS e utilizzare la tecnica descritta nella Sezione 9.

Quando non abbiamo bisogno di distinguere tra i diversi modi in cui il PE può essere informato dei prefissi di indirizzo che esistono in un dato sito, diremo semplicemente che il PE "apprende" le route da quel sito. Ciò include il caso in cui il PE è stato configurato manualmente con le route.

Prima che un PE possa ridistribuire una route VPN-IPv4 appresa da un sito, deve assegnare un attributo Route Target (vedi Sezione 4.3.1) alla route e può assegnare un attributo Site of Origin alla route.

L'attributo Site of Origin, se utilizzato, è codificato come una Route Origin Extended Community (Comunità estesa di origine della route) [BGP-EXTCOMM]. Lo scopo di questo attributo è identificare in modo univoco l'insieme di route apprese da un particolare sito. Questo attributo è necessario in alcuni casi per garantire che una route appresa da un particolare sito tramite una particolare connessione PE/CE non venga ridistribuita a quel sito tramite una diversa connessione PE/CE. È particolarmente utile se BGP viene utilizzato come protocollo PE/CE, ma a siti diversi non sono stati assegnati ASN diversi.