3. VRFs - Multiple Forwarding Tables in PEs (VRF - Tabelle di inoltro multiple nei PE)
3. VRFs: Multiple Forwarding Tables in PEs (VRF: Tabelle di inoltro multiple nei PE)
Ogni router PE mantiene un numero di tabelle di inoltro separate. Una delle tabelle di inoltro è la "tabella di inoltro predefinita". Le altre sono le "VPN Routing and Forwarding table" (tabelle di routing e inoltro VPN), o "VRF".
3.1. VRFs and Attachment Circuits (VRF e Attachment Circuit)
Ogni attachment circuit PE/CE è associato, tramite configurazione, a una o più VRF. Un attachment circuit associato a una VRF è chiamato "VRF attachment circuit".
Nel caso più semplice e tipico, un attachment circuit PE/CE è associato esattamente a una VRF. Quando un pacchetto IP viene ricevuto su un particolare attachment circuit, il suo indirizzo IP di destinazione viene cercato nella VRF associata. Il risultato di tale ricerca determina come instradare il pacchetto. La VRF utilizzata dal PE in ingresso di un pacchetto per instradare quel particolare pacchetto è chiamata "VRF in ingresso" del pacchetto. (C'è anche una nozione di "VRF in uscita" del pacchetto, situata presso il PE in uscita del pacchetto; questo è discusso nella Sezione 5.)
Se un pacchetto IP arriva tramite un attachment circuit che non è associato a nessuna VRF, l'indirizzo di destinazione del pacchetto viene cercato nella tabella di inoltro predefinita e il pacchetto viene instradato di conseguenza. I pacchetti instradati secondo la tabella di inoltro predefinita includono pacchetti da router P o PE vicini, nonché pacchetti da attachment circuit rivolti al cliente che non sono associati a VRF.
Intuitivamente, si può pensare alla tabella di inoltro predefinita come contenente "rotte pubbliche" e alle VRF come contenenti "rotte private". Si può analogamente pensare ai VRF attachment circuit come "privati" e agli attachment circuit non VRF come "pubblici".
Se un particolare VRF attachment circuit collega il sito S a un router PE, la connettività da S (tramite quell'attachment circuit) può essere limitata controllando l'insieme di route inserite nella VRF corrispondente. L'insieme di route in quella VRF dovrebbe essere limitato alle route che portano a siti che hanno almeno una VPN in comune con S. Quindi un pacchetto inviato da S tramite il VRF attachment circuit può essere instradato dal PE a un altro sito S' solo se S' è nella stessa VPN di S. Cioè, la comunicazione (tramite il router PE) è impedita tra qualsiasi coppia di siti VPN che non hanno alcuna VPN in comune. La comunicazione tra siti VPN e siti non VPN è impedita escludendo le route verso i siti VPN dalla tabella di inoltro predefinita.
Se ci sono più attachment circuit che portano da S a uno o più router PE, allora potrebbero esserci più VRF che potrebbero essere utilizzate per instradare il traffico da S. Per limitare correttamente la connettività di S, lo stesso insieme di route deve esistere in tutte le VRF. In alternativa, diverse restrizioni di connettività possono essere imposte tramite diversi attachment circuit da S. In tal caso, alcune delle VRF associate agli attachment circuit di S conterranno insiemi di route diversi rispetto ad altre.
Consentiamo il caso in cui un singolo attachment circuit sia associato a un insieme di VRF, piuttosto che a una singola VRF. Ciò può essere utile se si desidera partizionare una singola VPN in diverse "sotto-VPN", ciascuna con diverse restrizioni di connettività, e utilizzare alcune caratteristiche dei pacchetti del cliente per scegliere tra le sotto-VPN. Tuttavia, per semplicità, parleremo generalmente come se un attachment circuit fosse associato a una singola VRF.
3.2. Associating IP Packets with VRFs (Associazione di pacchetti IP alle VRF)
Quando il router PE riceve un pacchetto da un dispositivo CE, deve determinare l'attachment circuit su cui è arrivato il pacchetto, poiché ciò determina a sua volta la VRF (o l'insieme di VRF) che può essere utilizzata per inoltrare quel pacchetto. In generale, per determinare l'attachment circuit su cui è arrivato un pacchetto, il router PE prende nota dell'interfaccia fisica su cui è arrivato il pacchetto e possibilmente anche di alcuni aspetti dell'intestazione di Livello 2 del pacchetto. Ad esempio, se l'attachment circuit in ingresso del pacchetto è un Frame Relay VC, l'identità dell'attachment circuit può essere determinata dall'interfaccia fisica Frame Relay su cui è arrivato il pacchetto, insieme al campo Data Link Connection Identifier (DLCI) nell'intestazione Frame Relay del pacchetto.
Sebbene la conclusione del PE che un particolare pacchetto sia arrivato su un particolare attachment circuit possa essere determinata in parte dall'intestazione di Livello 2 del pacchetto, occorre assicurarsi che non sia possibile per un cliente ingannare l'SP facendogli credere che un pacchetto ricevuto su un attachment circuit sia in realtà arrivato su un altro, scrivendo nei campi dell'intestazione. Nell'esempio sopra, sebbene l'attachment circuit sia determinato in parte dall'ispezione del campo DLCI nell'intestazione Frame Relay, questo campo non è un campo che il cliente può impostare liberamente. Piuttosto, deve essere impostato su un valore specificato dall'SP, altrimenti il pacchetto non arriverà al router PE.
In alcuni casi, un particolare sito può essere diviso dal cliente in diversi "siti virtuali". L'SP può designare un insieme specifico di VRF da utilizzare per instradare i pacchetti da quel sito e consentire al cliente di impostare alcune caratteristiche nel pacchetto e quindi utilizzare tale caratteristica per scegliere una particolare VRF dall'insieme.
Ad esempio, ogni sito virtuale potrebbe essere implementato come una VLAN. L'SP e il cliente potrebbero concordare che per i pacchetti provenienti da un particolare CE, determinati valori VLAN identificheranno determinate VRF. Naturalmente, se i pacchetti provenienti da quel CE portano valori di tag VLAN che non sono nell'insieme concordato, il PE scarterà quei pacchetti. Un altro modo per ottenere ciò sarebbe utilizzare l'indirizzo IP di origine. In questo caso, il PE utilizza l'indirizzo IP di origine nel pacchetto ricevuto dal CE, insieme all'interfaccia su cui viene ricevuto il pacchetto, per assegnare il pacchetto a una particolare VRF. Anche in questo caso, il cliente può scegliere solo tra l'insieme specifico di VRF che gli è consentito utilizzare.
Se si desidera che un particolare host si trovi in più siti virtuali, tale host deve determinare, per ogni pacchetto, a quale sito virtuale è associato. Può farlo, ad esempio, inviando pacchetti da diversi siti virtuali su diverse VLAN o tramite diverse interfacce di rete.
3.3. Populating the VRFs (Popolamento delle VRF)
Con quale insieme di route viene popolata una VRF?
Come esempio, siano PE1, PE2 e PE3 tre router PE e CE1, CE2 e CE3 tre router CE. Supponiamo che PE1 apprenda da CE1 le route raggiungibili nel sito di CE1. Se PE2 e PE3 sono collegati rispettivamente a CE2 e CE3, e se esiste una VPN V che contiene CE1, CE2 e CE3, allora PE1 utilizza BGP per distribuire a PE2 e PE3 le route che ha appreso da CE1. PE2 e PE3 utilizzano queste route per popolare le VRF associate, rispettivamente, ai siti di CE2 e CE3. Le route provenienti da siti che non si trovano nella VPN V non appaiono in queste VRF, il che significa che i pacchetti provenienti da CE2 o CE3 non possono essere inviati a siti che non si trovano nella VPN V.
Quando diciamo che il PE "apprende" le route dal CE, non presupponiamo alcuna particolare tecnica di apprendimento. Il PE può apprendere le route tramite un protocollo di routing dinamico, ma può anche "apprendere" le route se tali route sono configurate (cioè, route statiche). (In questo caso, dire che il PE ha "appreso" le route dal CE può essere una certa licenza poetica.)
Il PE deve anche apprendere da altri PE le route che appartengono a una determinata VPN. Le procedure utilizzate per popolare le VRF con il corretto insieme di route sono specificate nella Sezione 4.
Se ci sono più attachment circuit da un particolare router PE a un particolare sito, potrebbero corrispondere tutti alla stessa tabella di inoltro. Ma se c'è una policy che lo impone, potrebbero corrispondere a diverse tabelle di inoltro. Ad esempio, la policy potrebbe essere che un particolare attachment circuit dal sito venga utilizzato solo per il traffico intranet, mentre un altro attachment circuit da quel sito venga utilizzato solo per il traffico extranet. (Il CE collegato all'attachment circuit extranet è forse un firewall mentre il CE collegato all'attachment circuit intranet non lo è.) In tal caso, i due attachment circuit sarebbero associati a VRF diverse.
Si noti che se due attachment circuit sono associati alla stessa VRF, i pacchetti ricevuti dal PE su uno saranno in grado di raggiungere esattamente lo stesso insieme di destinazioni dei pacchetti ricevuti dal PE sull'altro. Quindi due attachment circuit non possono essere associati alla stessa VRF a meno che ciascun CE non si trovi esattamente nello stesso insieme di VPN dell'altro.
Se un attachment circuit porta a un sito che si trova in più VPN, l'attachment circuit può comunque essere associato a una singola VRF, nel qual caso quella VRF conterrà route dall'insieme completo di VPN a cui appartiene il sito.