3. VRF - Molteplici tabelle di inoltro nei PE

3. VRF: molteplici tabelle di inoltro nei PE (VRFs: Multiple Forwarding Tables in PEs)

Ciascun router PE mantiene diverse tabelle di inoltro (forwarding table) indipendenti tra loro. Una di queste è la "tabella di inoltro predefinita" (default forwarding table); le altre sono le "tabelle di instradamento e inoltro VPN" (VPN Routing and Forwarding table), o "VRF".

3.1. VRF e circuiti di attacco (VRFs and Attachment Circuits)

Ciascun circuito di attacco PE/CE è associato, mediante configurazione, a uno o più VRF. Un circuito di attacco associato a un VRF è detto "circuito di attacco VRF" (VRF attachment circuit).

Nel caso più semplice e tipico, un circuito di attacco PE/CE è associato esattamente a un VRF. Quando un pacchetto (packet) IP è ricevuto su un determinato circuito di attacco, il suo indirizzo di destinazione IP viene cercato (lookup) nel VRF associato. Il risultato di tale ricerca determina come inoltrare il pacchetto. Il VRF usato dal PE di ingresso di un pacchetto per inoltrarlo è detto "VRF di ingresso" (ingress VRF) di quel pacchetto. (Esiste anche il concetto di "VRF di uscita" (egress VRF), situato sul PE di uscita del pacchetto; ciò è discusso nella sezione 5.)

Se un pacchetto IP arriva su un circuito di attacco non associato a un VRF, l'indirizzo di destinazione del pacchetto viene cercato nella tabella di inoltro predefinita e il pacchetto è inoltrato di conseguenza. I pacchetti inoltrati secondo la tabella di inoltro predefinita includono i pacchetti provenienti dai router P o PE adiacenti, nonché i pacchetti provenienti da circuiti di attacco orientati al cliente non associati a VRF.

Intuitivamente, si può considerare la tabella di inoltro predefinita come contenente le "route pubbliche" (public route), e i VRF come contenenti le "route private" (private route). Allo stesso modo, si possono considerare i circuiti di attacco VRF come "privati" e i circuiti di attacco non VRF come "pubblici".

Se un particolare circuito di attacco VRF collega il sito S a un router PE, la connettività da S (tramite quel circuito) può essere limitata controllando l'insieme delle route inserite nel VRF corrispondente. L'insieme delle route in quel VRF deve essere limitato alle route verso i siti che condividono almeno un VPN con S. Così, un pacchetto inviato da S tramite un circuito di attacco VRF può essere inoltrato dal PE a un altro sito S' solo se S' appartiene a uno dei VPN comuni a S. In altre parole, qualsiasi comunicazione (tramite i router PE) tra due siti VPN privi di un VPN comune viene impedita. La comunicazione tra siti VPN e siti non VPN viene impedita mantenendo le route verso i siti VPN fuori dalla tabella di inoltro predefinita.

Se esistono più circuiti di attacco che vanno da S a uno o più router PE, possono esserci più VRF utilizzabili per inoltrare il traffico (traffic) da S. Per limitare correttamente la connettività di S, lo stesso insieme di route deve esistere in tutti questi VRF. In alternativa, si possono imporre restrizioni di connettività diverse su diversi circuiti di attacco da S. In tal caso, alcuni dei VRF associati ai circuiti di attacco di S conterrebbero insiemi di route diversi da altri.

Consentiamo anche il caso in cui un singolo circuito di attacco sia associato a un insieme di VRF anziché a un singolo VRF. Ciò è utile se si desidera suddividere un singolo VPN in più "sub-VPN" (sub-VPN), ciascuno con diverse restrizioni di connettività, dove una caratteristica dei pacchetti del cliente è usata per selezionare il sub-VPN. Per semplicità, parleremo di solito di un circuito di attacco come associato a un singolo VRF.

3.2. Associazione dei pacchetti IP ai VRF (Associating IP Packets with VRFs)

Quando un router PE riceve un pacchetto da un dispositivo CE, deve determinare il circuito di attacco tramite cui il pacchetto è arrivato, poiché ciò determina a sua volta il VRF (o l'insieme di VRF) che può essere usato per inoltrarlo. In generale, per determinare il circuito di attacco tramite cui un pacchetto è arrivato, un router PE prende nota dell'interfaccia (interface) fisica su cui il pacchetto è arrivato, e possibilmente di un aspetto dell'header di livello 2 (layer 2 header) del pacchetto. Ad esempio, se il circuito di attacco di ingresso di un pacchetto è un VC Frame Relay, l'identità del circuito di attacco può essere determinata dall'interfaccia fisica Frame Relay su cui il pacchetto è arrivato, insieme al campo DLCI (Data Link Connection Identifier) nell'header Frame Relay del pacchetto.

Sebbene la conclusione del PE secondo cui un particolare pacchetto è arrivato su un particolare circuito di attacco possa essere determinata in parte dall'header di livello 2 del pacchetto, deve essere impossibile per un cliente, scrivendo i campi di header, ingannare il SP facendogli credere che un pacchetto ricevuto su un circuito di attacco sia in realtà arrivato su un altro. Nell'esempio precedente, sebbene il circuito di attacco sia determinato in parte ispezionando il campo DLCI dell'header Frame Relay, tale campo non può essere impostato liberamente dal cliente; deve essere impostato su un valore specificato dal SP, altrimenti il pacchetto non raggiungerebbe affatto il router PE.

In alcuni casi, un particolare sito può essere suddiviso dal cliente in più "siti virtuali" (virtual site). Il SP può designare un particolare insieme di VRF da usare per inoltrare i pacchetti di quel sito e può consentire al cliente di impostare una caratteristica del pacchetto, che viene quindi usata per selezionare un particolare VRF nell'insieme.

Ad esempio, ciascun sito virtuale può essere realizzato come un VLAN. Il SP e il cliente possono concordare che sui pacchetti provenienti da un determinato CE, alcuni valori VLAN identifichino certi VRF. Naturalmente, i pacchetti da quel CE verrebbero scartati (discard) dal PE se portassero valori di tag (tag) VLAN non inclusi nell'insieme concordato. Un altro modo per ottenere ciò è usare gli indirizzi IP sorgente. In tal caso, il PE usa l'indirizzo IP sorgente in un pacchetto ricevuto dal CE, insieme all'interfaccia su cui il pacchetto è ricevuto, per assegnare il pacchetto a un particolare VRF. Anche qui, il cliente potrebbe selezionare solo tra l'insieme particolare di VRF che gli è consentito usare.

Se si desidera che un particolare host (host) appartenga a più siti virtuali, tale host deve determinare, per ciascun pacchetto, il sito virtuale a cui il pacchetto è associato. Ciò può essere fatto, ad esempio, inviando pacchetti di diversi siti virtuali su diversi VLAN, o tramite diverse interfacce di rete.

3.3. Popolamento dei VRF (Populating the VRFs)

Con quale insieme di route vengono riempiti i VRF?

Ad esempio, siano PE1, PE2 e PE3 tre router PE, e CE1, CE2 e CE3 tre router CE. Supponiamo che PE1 apprenda (learn), da CE1, le route raggiungibili sul sito di CE1. Se PE2 e PE3 sono rispettivamente collegati a CE2 e CE3, e se esiste un VPN V contenente CE1, CE2, CE3, allora PE1 usa BGP per distribuire a PE2 e PE3 le route apprese da CE1. PE2 e PE3 usano tali route per popolare i VRF che associavano rispettivamente ai siti di CE2 e CE3. Le route dei siti non presenti nel VPN V non compaiono in questi VRF, il che significa che i pacchetti da CE2 o CE3 non possono essere inviati a siti al di fuori del VPN V.

Quando diciamo che un PE "apprende" route da un CE, non presupponiamo alcuna tecnica di apprendimento particolare. Il PE può apprendere route tramite un algoritmo di instradamento dinamico, ma può anche "apprendere" route configurandole (cioè instradamento statico, static routing). (In quest'ultimo caso, dire che il PE ha "appreso" le route dal CE è forse una certa licenza retorica.)

I PE devono inoltre apprendere, da altri PE, le route appartenenti a un dato VPN. Le procedure per popolare i VRF con i giusti insiemi di route sono specificate nella sezione 4.

Se esistono più circuiti di attacco che vanno da un particolare router PE a un particolare sito, essi possono essere tutti mappati sulla stessa tabella di inoltro. Ma se la politica lo richiede, possono essere mappati su tabelle di inoltro diverse. Ad esempio, la politica può stabilire che un particolare circuito di attacco da un sito sia usato solo per il traffico di intranet, mentre un altro circuito da quel sito sia usato solo per il traffico di extranet. (Ad esempio, il CE collegato al circuito di extranet è un firewall, mentre il CE collegato al circuito di intranet non lo è.) In tal caso, i due circuiti di attacco sarebbero associati a diversi VRF.

Notare che se due circuiti di attacco sono associati allo stesso VRF, allora i pacchetti che il PE riceve sull'uno potranno raggiungere esattamente lo stesso insieme di destinazioni di quelli ricevuti sull'altro. Due circuiti di attacco non possono quindi essere associati allo stesso VRF, a meno che ciascun CE non appartenga esattamente allo stesso insieme di VPN dell'altro.

Se un circuito di attacco conduce a un sito che è in più VPN, il circuito di attacco può ancora essere associato a un singolo VRF, nel qual caso il VRF conterrà le route dell'intero insieme dei VPN di cui il sito è membro.